Wedge

How well did it work out for you?

I never did find out how well Dream Portal's plugins stuff did, I was vaguely aware of what one had to do to create such a thing but I never made any, and I remember being something related to amazement at seeing raw PHP embedded into XML,[1] but anything other than that, I don't remember, and I might even be remembering that incorrectly.

(Note that I'm not looking to remove the existing <settings> block which is used for settings defaults and housekeeping, because plugins that don't use this setup because it's too limiting, e.g. WedgeDesk, will still use <settings> to clean up after removal)

1.	Since unless I'm much mistaken, that's eval() right there...

While there is an implied performance aspect (since the admin menu has to be evaluated every page of the admin area) it's not a great stretch to actually cache all the active plugins' details and evaluate them in a single hit.

Had a random idea about this today. The plugin info file already lists all the $settings variables that a plugin uses (so that it can set defaults and clean up properly later) but I've been thinking about the interface side of things.

Right now, if a plugin wants to add a settings page, even a simple one, it's going to have to create a file, use at least two hooks[1] and create a stub file that is almost entirely identical from plugin to plugin. Heck, when I start a plugin now that uses a simple settings page, I just copy everything from an earlier one.

So, here's what I'm thinking. Everything that you would normally have to set up for a settings page ($config_vars etc.) can be streamlined. Of course, more complex plugins (of the likes of WedgeDesk) would still do their own thing, but the smaller stuff could be simplified.

For example, I have a stub plugin that will grow into a big scary share-topics-with-services monster, dubbed Flitter because it was originally just Facebook + Twitter. Right now, it's very straightforward however, with its settings page being:


Then you have a function which binds to the admin menu, and the rest of the boilerplate in this function that's used for saving and calling the relevant templates and stuff. It gets set up as action=admin;area=flitter and uses 'Flitter' as the title (which is the plugin's title anyway)

I'm thinking we could handle this in the plugin-info.xml file directly instead.


Assuming the plugin author uses this, it should be able to handle the menu item, the settings themselves, making them searchable and auto-linking it in the plugins area (minimising the need for using the <acp-url> element though not obsoleting it)

The area= part specifies what admin area it should be, the icon is the icon for the dropdown menu, the bigicon is the big icon to use, <load-language> identifies what language file(s) should be loaded when running the page, so that the relevant strings can be loaded. Everything else just correlates to the above.

Personally, I think it's less effort for the plugin developer generally, it's less they have to deal with - you don't expressly have to deal with hooks when doing this and you're still doing less work than you would doing it manually.

Thoughts?

1.	Three if you want to make it searchable as well, yup, even that isn't automated.

Yeah I see what you mean about not feeling natural.

I LIKE IT! That said, I see your point about finding the end div, and I don't think there's a good way to solve that at all, sadly.

*nods* Well... I did spend some time last night poking at it and trying to break stuff, and more than once I wondered idly if I was doing it wrong or not - no matter what I did, it seemed like I could only have the sidebar on the right, or on the left above the content (because it wasn't floating correctly) but that in hindsight could just as easily have been me doing it wrong heh - yesterday was a very strange day for me in a lot of ways, nothing really made perfect sense...

Though looking at the latest rev, seems that it might have been more than just me that was intrigued by it.Well, I might switch it out for a class, that way the theme can control it how they see fit.This is the problem, ultimately, with skins vs themes; sometimes the theme code just doesn't allow for a given combination of styling - so you end up having to have alternative markup available.Babylon is still well designed. It's just not quite what I want from a theme, and I find the smoother gradients in Core make it more palatable for me personally.I'm sensing a touch of overkill here - most admins don't actually care whether it's correct or not. Plugins almost certainly won't be correct anyway.

The other thing is, does it make a difference in gzip size? I know that sometimes you can end up saving far less than you thought by not removing things like spaces.

http://www.simplemachines.org/community/index.php?topic=469381.0

I'm disappointed it's taken this long to actually get some kind of announcement about SMF's future - it's been about 8 months since 2.0's gold release, and it sounds like 2.1 isn't making great strides, but it's making *something*, which is a good thing.

I'm not clear on exactly what they mean by the security tokens stuff, and by 'mod/admin sessions' (especially considering what's in SMF already) but the other stuff seems fairly run of the mill for 2.1 itself.

The announcement of 3.0 / smCore is nothing surprising, it's been talked about many times over the years but little has thus far come of it - but you never know. Going for the MVCS approach isn't a bad one (it's cleaner in most cases than MVC itself usually produces) either.

Intriguing but it feels a bit like 'we're not dead yet, honest' to me :(