Multisite Compatibility

ResolvedPlugin Contributor codejp3
(@codejp3)

1 year, 4 months ago

As it stands, this plugin will work with multisite installs, but whatever ONE site (any site) sets in the option tabs applies to ALL sites.

For a multisite install where the bbPress forum is SUPPOSED to look identical on every sub-site, that’s fine. For multisite installs where each site should be able to style the forum independently, this is a problem.

I’ve tested it, and the “independent styling” is a problem whether bsp is network-activated, or optionally activated on a per-site basis.

Do you have any plans to make this plugin multisite-friendly?

It could be as simple as:

1.) if network activated, provide a network admin option to choose – ONE style for ALL sites, or Independent styles for EACH site.

2.) if network-activated and network admin option set to “ONE style” – display the bsp settings only in the network admin panel, generate single files from saved settings like it currently does, and enqueue those files for EVERY site.

3.) if network-activated and network option set to “Independent styles” or plugin is NOT network-activated – then display bsp settings within each site admin panel like it currently does, and generate individual files per site ID, enqueuing only the files for each site individually.

DB settings are currently being saved in a “multisite-friendly” way, per-site. The only thing really preventing this plugin from being fully multisite-friendly is the generated file names and how those files are enqueued. Maybe ONE style for ALL sites is fine, but maybe INDIVIDUAL styles for EACH site is what the network admin wants. Only thing preventing that from happening is file names/enqueueing, and the network admin option for selecting which way to apply bsp styles.

Just wanted to plant the seed for this.

If you’re OK adding yet another layer of complication to this plugin for the sake of full multisite compatibility, I’ll gladly contribute. If you have no desire to add full multisite compatibilty, then I’ll leave this one alone.

Viewing 15 replies - 16 through 30 (of 36 total)

← 1 2 3 →

Plugin Contributor codejp3
(@codejp3)

1 year, 2 months ago

@robin-w – 5.2.6 updated to fix the quote/tinymce issue. Details here:

https://wordpress.org/support/topic/quotes-not-working-with-text-editor-only/#post-16415878

Plugin Author Robin W
(@robin-w)

1 year, 2 months ago

just released 5.2.6

Plugin Contributor codejp3
(@codejp3)

1 year, 2 months ago

Keeping a close eye on the support forum over the next few days….

Plugin Contributor codejp3
(@codejp3)

1 year, 2 months ago

@robin-w – 5.2.7 published on GitHub:
https://github.com/codejp3/bbp-style-pack/tree/5.2.7

Direct Download:
https://github.com/codejp3/bbp-style-pack/archive/refs/heads/5.2.7.zip

Fixes 2 reported Bugs:
1.) Missing Widgets
2.) Unread Icon Placement/Alignment

Both fixes took place in /bbp-style-pack.php dealing with the included files for frontend/admin/both, and their order.

Other than that, so far so good. I’ll keep checking for any more reported bugs tomorrow and over the weekend.

Plugin Author Robin W
(@robin-w)

1 year, 2 months ago

thanks, I’ve updated and released 5.2.7.

We seem to have an issue on update from 5.2.6 to 5.2.7 in that css is not regenerated, and the bsp_version number in the database does not change.

This is on single site, don’t know if it affects multi-site

Can you take a look, as you’ll be faster to see why than me
Plugin Author Robin W
(@robin-w)

1 year, 2 months ago
from a quick look, generate_style_css() also looks for BSP_PLUGIN_DIR which is not yet defined on update or activation, it is further down the code (line 150) , so maybe this just needs moving to the start of the bbp-style-pack.php as well?
- This reply was modified 1 year, 2 months ago by Robin W.
Plugin Author Robin W
(@robin-w)

1 year, 2 months ago
or given that $bsp_css_location is also later in code, maybe move the activation section below the global variables and before bbp_style_pack_init()
- This reply was modified 1 year, 2 months ago by Robin W.
Plugin Author Robin W
(@robin-w)

1 year, 2 months ago

by the way I have changed includes/functions_topic_count for another reason, so can you use the published version in any new updates

Plugin Author Robin W
(@robin-w)

1 year, 2 months ago

just been testing, register_activation_hook does not run on an update as far as I can see, so no bspstyle.css file(s) exist after an update, the plugin wipes them out unless stored elsewhere.

so we probably need to run function bsp_plugin_activation right at the start if (!file_exists…. bspstyle.css) or do the versioning on a plugins loaded rather than activation???

Plugin Contributor codejp3
(@codejp3)

1 year, 2 months ago

Working on it.

I’ll have 5.2.8 posted with:

1.) activation hook function/version updating properly
2.) your topic count changes
3.) a few extra “if isset()” checks within settings files to prevent the dozen or so “Warning: Trying to access array offset on value of type bool” messages that keep popping up in my debug log

….probably be ready later today

Plugin Contributor codejp3
(@codejp3)

1 year, 2 months ago

@robin-w

GitHub “main” branch updated to the current 5.2.7 version you just published:
https://github.com/codejp3/bbp-style-pack

5.2.8 branch created:
https://github.com/codejp3/bbp-style-pack/tree/pre-pub-5.2.8

Side-by-side comparison:
https://github.com/codejp3/bbp-style-pack/compare/pre-pub-5.2.8?expand=1

Direct Download:
https://github.com/codejp3/bbp-style-pack/archive/refs/heads/pre-pub-5.2.8.zip

Code Change Highlights:

1.) /bsp-style-pack.php
– activation hook moved to the bottom (probably unnecessary, but did it anyways)
– new plugin update hook added that performs the activation actions on plugin update

2.) /includes/functions.php
– new function added to check custom CSS locations
– now also checks if dir exists, and if dir is writable
– returns empty array if all checks pass
– returns an array of current error messages for specified custom CSS location
– messages re-done to be translatable gettext strings

3.) /includes/generate_css.php
– only generate/enqueue custom CSS location files if there are no errors with the custom location (uses function in #2 above) (prevents 500 server errors I was getting when I intentionally gave bad locations)

4.) /includes/settings_css_location.php
– extra “isset()” checks for text input fields to prevent PHP array index warnings
– direct error handling removed from file
– now displays error messages returned by function in #2 above

5.) /includes/settings_breadcrumbs.php
– extra “isset()” checks for text input fields to prevent PHP array index warnings

6.) Topic count files are identical to what was in the official 5.2.7 (now the main branch) so your changes should be intact.
Plugin Author Robin W
(@robin-w)

1 year, 2 months ago
I am less convinced that we use the ‘upgrader_process_complete’ hook, I looked at this function yesterday. It doesn’t run in a number of circumstances, and when it does run, it fires code from the old plugin version. I don’t know if on first version use :
- it doesn’t run as not present in the old version
- runs but does nothing
- runs but errors as the code action hook function is not in the old version
- crashes the plugin as the functiion is not there
and I’m not really keen to find out by releasing to 8000 users.

I am tempted to do this :
```
$new_version = get_plugin_data( __FILE__, false, false )['Version'];
$curr_version = get_option( BSP_VERSION_KEY, false );
if (!empty ($curr_version) && $new_version != $curr_version)  {
	// first set whether network activated or not
    if ( ! function_exists( 'is_plugin_active_for_network' ) ) {
		require_once( ABSPATH . '/wp-admin/includes/plugin.php' );
    }
    $network_wide = ( is_multisite() && is_plugin_active_for_network( $bsp_name ) ) ? true : false; 
     
	 // do the activation actions
    bsp_plugin_activation( $network_wide );
}
```
Would this work for multisite?
Plugin Author Robin W
(@robin-w)

1 year, 2 months ago
@codejp3 – I have had to release 5.2.9 as I am getting grief from users on why updates keep breaking the site.

I did some further digging, and using either the ‘register_activation_hook’ or ‘upgrader_process_complete’ hooks breaks stuff, as bbpress is not loaded at that stage, and some code relies on it being there.

So I have reverted to the widely used and traditional method of using versions, and putting it within the bbpress class exists area so we know that bbpress is active when we do the file generations.

Given that under multisite you can only have one version of a plugin running accross a sites, then I am presuming that setting a global option of ‘bsp_version’ (which I am guessing an update_option without a site number does?) will catch any bsp update and regenerate css files for each site using your function ‘bsp_plugin_activation’ which I have renamed ‘bsp_plugin_update’ and looks like it works really well. settings the option in each db may or may not be needed, but does no harm I think? I have moved that ‘update_option’ down a bit as ‘update_option’ creates that option if not alreadty existing and saves an ‘if’ statement.

Anyway take a look, and if this breaks multisite for you, then I think we need to work on a fix which doesn’t require either hook and relies on a version number – open to your thoughts as I am now as keen as you to get this working well

Thanks again for your continued work on this – it is a major improvement, and we are nearly there thanks to you.
- This reply was modified 1 year, 2 months ago by Robin W.
Plugin Contributor codejp3
(@codejp3)

1 year, 2 months ago
@robin-w – I looked at the code for 5.2.9 to see what you ended up with. Overall I get it and like it. Serves the purpose of only regenerating files when needed, doesn’t rely on hooks that may or may not fire as intended, and waits until everything necessary is loaded.

One small tweak to the “Handle upgrade actions” code just around line 520-ish to take care of a debug message :

Only change here was adding:
```
$bsp_name = plugin_basename( __FILE__ );
```
before:
```
$network_wide = ( is_multisite() && is_plugin_active_for_network( $bsp_name ) ) ? true : false;
```
I was getting “WARNING: bsp_name is not defined” debug messages, and since it wasn’t defined, it always made $network_wide = false, so the bsp_plugin_update function didn’t do network-activated version updates or re-generations.

As an extra precaution, I added this check the top of the bsp_plugin_update function:
```
        if ( ! function_exists( 'get_plugin_data' ) ) {
                require_once( ABSPATH . '/wp-admin/includes/plugin.php' );
        }
```
Also, since the bsp_plugin_update function is now only called if “($new_version != $curr_version)”, I removed the duplicate check within the bsp_plugin_update function.

I went ahead and posted these changes to github as v5.3.0:
https://github.com/codejp3/bbp-style-pack/tree/pre-pub-5.3.0

Direct Download:
https://github.com/codejp3/bbp-style-pack/archive/refs/heads/pre-pub-5.3.0.zip

Playing around with it a little more before saying it’s 100% good-to-go, but that was the only issue I encountered on multisite.

Since I think I’m currently the only multisite user, the update probably isn’t critical to publish immediately. However, anyone who has debugging enabled will see the “WARNING: bsp_name is not defined” message, so that may justify publishing it sooner.
Plugin Author Robin W
(@robin-w)

1 year, 2 months ago

@codejp3 – thanks, and I’ll continue to thank you for all your help – I’ve learnt lots !

Yes – I’ll give it a day and if nothing comes back I’ll release a 5.3.0 version with your changes

🙂

Viewing 15 replies - 16 through 30 (of 36 total)

← 1 2 3 →

The topic ‘Multisite Compatibility’ is closed to new replies.