Multisite Compatibility

Dare I say it…. we might FINALLY be sorted and have a good solid “stable” starting point for all future additions ?? ….3 updates later ??

I do have some other projects to wrap up so I won’t be putting as much time into BSP, but as I use the plugin and notice things, I’ll fix/enhance them and send the code your way.

thanks – I’m away for 2 weeks from next Thursday – little trip to Egypt !!

Awesome! Enjoy it!

In the meantime, if you’re OK with it, list me as an official code commiter and I can handle minor updates to fix any reported issues from users until you get back.

What I may do during that 2 weeks is another update to whip the translations and gettext strings into shape. Took care of a good chunk already, but there’s still some strings not in gettext wrappers, and several that are not 100% gettext compliant or machine-translation-friendly. I’d wait until you got back before publishing it so you can view it first and have final say on what gets published (assuming you make me a code commiter).

@robin-w – got another multisite compatibility update coming your way either later today or tomorrow.

Plugins are handled differently with multisite and I noticed the plugin_info tab wasn’t displaying multisite plugins properly. I swear I was only going to address that ONE SINGLE THING …..but OF COURSE it lead to complete revamp of the entire plugin_info tab and how tabs are handled in-general. Quite a bit has changed so I’ll post it on GitHub so you can do the side-by-side comparison.

Until then, here’s a teaser pic ??

@codejp3 – I’m keen to do incremental change, and not do changes when you are working on things – You are working on changing how all the settings tabs work – is that nearing completion?

@robin-w –

I wish I could release this one in smaller chunks, but it’s a full re-write of how settings are handled so it really needs to be done all at once. Don’t freak out by me saying that either. The settings are largely untouched, but how they’re defined and rendered is completely new. It’ll make the settings page completely versatile where any setting field can be rendered on any tab, and “like” settings can be grouped together regardless of the option group they belong to. It also means that formatting and sanitizing of all settings is handled prior to saving to the DB. You were previously locked into only being able to render fields per-option group on a per-tab basis. This removes that limitation altogether. Changes to tabs/settings is now as simple as changing array values without ever touching any code. Adding a new tab or any new settings is simply defining an array for it. No need to touch any code unless it’s something non-standard. It removes all limitations that previously existed, and standardizes everything that’s currently there. Since less code has to be touched for future updates, it makes overlooked issues far less likely in the future.

I hope it’s near completion, but realistically it may be another two weeks. As usual, I’ll do a video or two covering all the important parts.

Your concerns are being integrated into the new revision.

It won’t get pushed out as an official stable update until we test it with some volunteer BETA testers first and iron out any bugs. Version 5.2.6 was a big learning lesson on that!

If you want/need to release any other updates prior to this one being ready, go for it. I’ll adapt them to the revision I’m doing.