News:

Want to get involved in developing SMF, then why not lend a hand on our github!

Main Menu

Rethinking blocks/widgets - more thoughts from other places

Started by Arantor, October 07, 2019, 07:09:37 PM

Previous topic - Next topic

Arantor

It's that time again, sharing some thoughts from the wider world.

The inspiration I had recently: it'd be great if SMF had a block system (like the portals have) built in. I'm all for having a portal as part of the core, in fact. This is a relatively recent conclusion for me though.

Some time ago I pondered the info center, the various things people want to do with it in themes, like display it with tabs, or splice in additional things, or change things, and I realised that instead of having theme settings/core settings/other settings, the best thing to do would be to make a block that people could edit in the relative comfort of a block editor.

(Well, what happened was that I concluded it should be a block that contains other blocks, which you can reorder at will, remove, tweak, whatever, you also get to deal with all the 'I don't want to show the info center to guests' questions, and plugins can supply new blocks that can slot in.)

But that got me thinking. If you're already in a place where you have blocks infrastructure, as core, what else does that get you? Interestingly, it gets you a surprising way - the moderation center home page, that's just blocks presented in a different way. The upper part of the admin home page, that's blocks too. What if these were hived off into their own classes (rather than spreading their dependencies all over the show), and configurable with minimal drama?

I still have a long way to go with this experimentation, but so far I'm pretty happy with it, I've gotten to the point where the info center template doesn't exist any more, and none of the code for it is in the board index, it's all buried away in a stash of block classes with tooling to make it all work, even expand/collapse works, but it's no longer a special case, it's just configuration now.

I guess I've been tainted by Moodle in that respect, where large amounts of things are blocks, and they're a major core API and many people just spam all kinds of crazy things into blocks, often because it's easier than trying to do other stuff, but it's also a convenient way to start programming in Moodle and a good block gets you a really long way in practice.

I guess also it's because SP is effectively stalled now, DP is all but gone, ADK portal doesn't work without help, leaving the only real portal choice going forward as TP and that seems too complex for a lot of people, partially because it's very powerful and partially because it does more than it probably should (meaning that swathes of functionality could one day become core but not all of it)

I dunno, complicated subject, but I think putting a block framework of some kind into SMF 2.2 or 3.0 is a major step forwards in practice, I'm certainly seeing how it might play out for me (e.g. admin page refactoring to include more widgets/blocks going forwards, more moderation center blocks etc.)

Antechinus

Makes a certain amount of sense. There are already some custom themes that provide something along these lines, in fairly rudimentary form.

Diego Andrés


SMF Tricks - Free & Premium Responsive Themes for SMF.

Antechinus

Oh hey, this reminds me of something.

In admin you're not allowed to input HTML to places like the news, board descriptions, etc. This is "for security", as I understand it. However, anyone with admin access can use the admin centre file editor to input HTML directly into any theme template, and HTML can be edited into any language string in the languages editor, and portals usually allow HTML, PHP and javascript in portal blocks.

So, I have to wonder what is gained by not allowing admins to use HTML in a few places. Not that I need to or want to use it in those places. It's just a general question.

Bloc

It certainly would lessen the need for portal mods to hackmod the core.. :D

I see other benefits too with such a system: standardized (sub)templates which makes it easier to theme consistently and better ways to show the blocks, especially on mobiles where there is less screen estate. 

Kindred

ant -- because when we allow html, people break things left and right...   with the theme editor, you KNOW that you're editing a theme.

Also, we get dinged on security scans for allowing html in those places (but not with the theme editor, interestingly enough)


Finally, I believe there are permissions to allow one to edit the news without full admin rights
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Antechinus


Arantor

Actually there's several permissions that are semi-admin permissions (manage news, manage boards, send newsletters, amongst others), and since they aren't necessarily full admins, you need to prevent them allowing full access to JavaScript which could be used to take over the admin account(s) via news, board descriptions, etc.

Also there is zero need for portals to hack the core, I had a proof of concept of all the standard "portal features" without a single code change. The hardest, incidentally, was fixing the jumpto selector.

d3vcho

I've been thinking about this for a while now. We've always been saying that for this kind of features users can always request a mod. Why should it be different in this particular case?
"Greeting Death as an old friend, they departed this life as equals"

Arantor

Quote from: Suki on October 08, 2019, 10:39:28 AM
How would you define the line between SMF + blocks and a full CMS with a block editor/wix web builder ?

Same way I define the difference between Moodle with its blocks and a full CMS with a block editor/Wix web builder; the two are still fundamentally different beasts, with comparisons that don't stand up to scrutiny.

Though I turn the question around: why is it inherently a good thing that SMF remains so true to its ideological purity of purpose? In fact, is it a good thing that it does? Is it a good thing that it remains 'only a forum'?

Is it really so bad to consider expanding the scope of what it could be by providing a framework for people to add things in, rather than relying on mods to even provide that framework? Mods which, I would remain everyone, are subject to disappearing - ADK, DP, UP, PortaMX, SP, none of these are maintained for SMF (SP lives on in a fork, but it's not the same thing), leaving this use case for EhPortal, TinyPortal and ezPortal...

Note I'm not suggesting articles or menu managers or page managers should be core, merely the block aspect. I see it as a feature that improves upon the core forum aspect, and so do various other forum platforms that have added such things to core. In fact, if we're comparing software, let's at least compare like for like, and instead of comparing a forum offering with a content management system, let's compare a pretty conservative forum with another pretty conservative forum - SMF vs XenForo. They added a block system, after realising 1) that mod authors were reimplementing this over and over and 2) they were using what amounted to blocks in the core platform and instead of reimplementing the wheel, they built a system to make it core.

Quote from: d3vcho(); on October 08, 2019, 10:41:13 AM
I've been thinking about this for a while now. We've always been saying that for this kind of features users can always request a mod. Why should it be different in this particular case?

Because you already have places where you already have this need and it has been reimplemented multiple times (in different ways) with different levels of quality.

Look at the moderation center home page. Is that not a collection of blocks?

Look at the stats page. Is that not a collection of blocks (of varying levels of complexity)?

Look at the admin home page. Is that not a menu with a pair of blocks on it?

Look at the forum front page? Isn't the info center really a block? (What if you thought of it in terms of blocks rather than the otherwise indivisible whole?)

Look at the calendar? Is that not a sidebar full of blocks I see there?

Hell, look at the unread page and see the block SimpleDesk added there on this site.

Why should it be different to adding a mod? Because it's something *you're already doing*, just extend it out from being a collection of special cases into something you can reuse as core functionality.

And if it means that people can have an easier time of making new things (think making a block as a plugin is going to be a smaller deal than other kinds of plugins, it becomes an entrance level plugin, then people can learn to go bigger), isn't that a good thing for a platform?



Can I suggest something? You've both told me repeatedly over the years that I should look more positively at things. Can I ask you to do the same? Instead of looking at a suggestion and immediately looking at why you perceive it as bad, start from 'what could I do with that if I had it?' Think about the uses you could make of it in mods if it already existed. Think about the ways you could do new and interesting things with it rather than seeing it as reinventing the wheel.

d3vcho

Quote from: Arantor on October 08, 2019, 11:06:37 AM
Can I suggest something? You've both told me repeatedly over the years that I should look more positively at things. Can I ask you to do the same? Instead of looking at a suggestion and immediately looking at why you perceive it as bad, start from 'what could I do with that if I had it?' Think about the uses you could make of it in mods if it already existed. Think about the ways you could do new and interesting things with it rather than seeing it as reinventing the wheel.

This is a discussion Arantor. As I've told you a few times already, we do appreaciate your suggestions and comments. I appreciate them a lot. What I said is a fact, it's a sentence that has been present in this boards for quite a while now. I want to know your full thoughts and your full opinions on things. If you weren't able to refute what that sentence says, then your whole thread would be pointless, but as you just showed, you could refuse it.

Please do not take it personal.
"Greeting Death as an old friend, they departed this life as equals"

Arantor

Quote from: Suki on October 08, 2019, 11:14:40 AM
It was just a question. Never in my post suggested any kind of negativity towards the idea.

Just a question, yes. The problem is that it's a question that immediately puts the idea into the negative by drawing it a false equivalency. The minute you frame a suggestion in a context like that, you immediately shoot it in the leg, because it's no longer 'how about adding blocks' but 'how to not turn it into Wix'. It's a hidden bias - why would it matter if it were turned into something like Wix? As long as the core ability to be a good forum is preserved, what does it matter that it might have taken on ideas other software has?

QuoteThis is a discussion Arantor. As I've told you a few times already, we do appreaciate your suggestions and comments. I appreciate them a lot. What I said is a fact, it's a sentence that has been present in this boards for quite a while now. I want to know your full thoughts and your full opinions on things. If you weren't able to refute what that sentence says, then your whole thread would be pointless, but as you just showed, you could refuse it.

Please do not take it personal.

The problem with 'we've always said' is that it's bull******. It's one of the most harmful concepts in software development. Because it's another rephrasing of 'we've always done it this way'. Which means 'we've never thought about whether the decision is still correct, we're just trusting it was correct when it was first taken and that must never, ever be changed'. (Brexit comes to mind. Circumstances never change, obviously)

There was a time I'd have been vocally against blocks being core. Because I had the same 'purity of purpose' argument. Until I realised that it was nonsense; blocks were already in the core.

My issue with such things, though, comes down to one thing: ideas shouldn't need to be immediately and reflexively defended. An idea should be able to be put forth and for people to be able to see its merits as well as its flaws, without having to actually defend its merits as an opening position.

That's one of the huge problems this place has, ideas don't just need to be suggested, they immediately need to be defended from the off, as though every idea is bad until it is rigorously defended as good, because it's clearly not possible to look at an idea and wonder if it has some value and merit just because it might have some without needing rigorous defence.

That is why I have an issue here: too many ideas get jumped on (including by me) without first looking at whether it has some merit. Too many times ideas get piled on with 'why it's not a good idea' before looking at any value of 'why it might be a good idea'.

This idea didn't need defending on its own; the culture made it so because the idea runs counter to the culture here, the culture that we must mostly do what we've always done because that's what we've always done.

I dispute that this was 'a discussion', because it didn't look or feel like one, but don't worry, lesson has been learned. Every future idea will just be submitted with a wall of text defending it. Or maybe I'll just not bother sharing what I've discovered by trying to do things.

Bloc

Its true various places are divided into "modules" or "blocks" if you like, in SMF...but they are still quite different from the way for example blocks are built in portal mods like TinyPortal. For instance, in TP they are shown according to rules which can carry them over several pages/sections , be visible to certain users etc.

If said built-in modules in SMF - like recent posts in Infocenter - were built-in blocks, should they also have that capability? If they do, would that not increase the page load, just as portals do now? And if the SMF block implementation does NOT have that option - why then add it? Save for the splitting of "parts" of the forum....which incidentally  dividing sections into more subtemplates would give the same effect.

In that light TP would still need to create the logic and possibly also carry the code, for a recent posts block to show on other pages. I am not saying SMF should have that option - but it was , at least for me, a big incentive when I created TP. That is, creating surrounding content that would or could show in different places.

Arantor

Should they? Of course they should. Maybe not quite so extensively as TP does it but the underlying functionality should be there.

Does it increase the page load? Yes - but that's where it starts to get interesting. If you're building something with this in mind from the start, or at the very least building something that doesn't have to care about how easily it slots in because you're making it core and thus can do what you like, you can actually pay off some of the increased load in the building.

In fact, in my testing, the increased cost of what I have is basically just the one database query for getting the blocks; pretty much everything else is sufficiently small compared to the rest of the system it doesn't really matter (but testing is ongoing as I haven't moved everything over yet)

I also come from a system where adding subtemplates is much simpler than trying to do it in SMF and where a theme can replace out an individual subtheme completely independently of the template whole, so for each block in the system I have its own template for its content, plus a collection of templates for the block wrapper around it. To the point where in my setup, the look of the info center can be obtained out of the box with only configuration (because I can have a block that contains a block)

This does have some other interesting consequences; moving things around inside the info center, or putting new things inside the info center is now a matter of configuration rather than code - because you can dump more blocks into it if you so desire. Things like SMF used to do, putting the 'live from SMF' news into the moderation center becomes trivially doable because it becomes adding a block in the right place with configuration rather than code.

If we're going to frame this in the least flattering light possible for an idea, which I guess we now have to do because that's the only frame of reference people have... I guess I'm suggesting the next version of SMF should have a portal built into it, in the sense of a portal being a block manager. And then it should change existing parts of the platform to also use that block manager, and the cost of running the portal is amortised across the use of the whole platform.

Antechinus

As long as it can be made to perform well on large sites, with reasonable resources thrown at it, it sounds like a good idea.

Quote from: Arantor on October 08, 2019, 02:16:39 AM
Actually there's several permissions that are semi-admin permissions (manage news, manage boards, send newsletters, amongst others...

By the way, is the Current Theme page included in these "semi-admin" permissions? Or is that one only accessible to the real McCoy?

Arantor

QuoteAs long as it can be made to perform well on large sites, with reasonable resources thrown at it, it sounds like a good idea.

I can't imagine that being a problem - it hasn't shown (so far) on my test site to be problematic.

QuoteBy the way, is the Current Theme page included in these "semi-admin" permissions? Or is that one only accessible to the real McCoy?

Theme admin (including Current Theme) is admin_forum only, as is package manager and manage languages, which are the key places that people can get PHP onto a server.

Antechinus

Cool. Makes sense. So allowing custom html into inputs on current theme settings isn't really any worse that what's there already?

Arantor


Bloc

Adding more blocks quickly add the count of queries..thats one of the main obstacles in using a portal. Not built-in ones that can spread the load, be optimized but the ones that get added by mods and admins. I would be excited to have a block feature for SMF, don't get me wrong :) but that increase in resources was always a problem. After I stopped working on TP, I even just added portal-like features as optimised code to my custom SMF site instead of using TP, mimicking more or less its features but without the overhead...and in some custom themes I've also toyed with block-like features. It always comes down how well its optimised.

More than anything I guess it would be a shift in how SMF sees itself: not as a CMS, not even as a portal(which is somewhat negatively loaded word, true) but as modular forum system instead of "just" a forum system. IMHO that would be a next logical step.

Arantor

I don't see why ones added by mods can't do the same kind of caching that the core ones do. I honestly don't see why that should ever be a problem - just because existing portals today may have chosen not to do that, doesn't mean future ones can't.

And yes, I very much view the notion of adding a block system as the next logical iteration for modularity (and why I'm so agitated by loaded terminology like portals because it carries a whole weight that shouldn't be there).

Advertisement: