KZeni

It seems like the content being included in the feed needs to actually display the special characters instead of trying to use the HTML entities.

To confirm this, I used the direct input method on https://validator.w3.org/feed/ with your feed’s source and replaced &Agrave ; with à as well as &#039 ; with ' (needed to add a space before the ; in this example which isn’t actually there since this comment wants to auto-convert it to the special character) in any/all occurrences (seems like a requirement for the entire XML file’s contents) and it showed the feed was then valid (which is certainly better than needing to remove those characters or trying to replace them with a similar character.)

So, the fix is probably something to the effect of updating https://plugins.trac.www.ads-software.com/browser/simple-history/trunk/dropins/class-rss-dropin.php so that any content being output is wrapped in html_entity_decode to avoid this.

While I’m not the developer, hopefully this (or similar) can be implemented in a future version release.

Also, it’d probably be good to swap out your feed’s secret key so this isn’t kept public, I’d assume.

Yup. It’s been a confirmed issue in version 4.2.0 with no official fix or remediation of the problematic version release for more than 3 days now.

I detailed things in https://www.ads-software.com/support/topic/fatal-error-4488/#post-16894036 (with the linked comment having its first paragraph outline a workaround for affected sites), and the plugin developer said they’d release a fix “today or tomorrow” 3 days ago at https://www.ads-software.com/support/topic/php-error-in-lastest-version/#post-16883963.

Broken version releases like this either need to be taken off WP.org (effectively undo the problematic version release), have the previous release be re-released as the new version until a proper fix is available to then re-release the then-fixed version (with hopes that any site that happened to get the bad version might then update to effectively undo the broken release on the site), or (time allowing) have the broken version be fixed much quicker than this since delaying doing any of this just lets more & more sites encounter the problem as they eventually all update to that latest version (especially when 200k+ sites use a plugin like in this case & definitely when that broken release is available for more than 8 or so hours per a common auto-update interval [when it really should be fixed in less than an hour after acknowledgement since those first two options I mentioned here of just reverting the problematic release would take a matter of minutes to do.])

I’m thinking they’re trying to fix the version 4.2.0 release to then make available which is then taking longer (it’d explain why it’s been days, at least) when they really should’ve reverted the broken version release first & foremost to stop the spread and then proceed from there.

I’m a bit confused. You say “newest version”, but the newest version is 4.2.0 (released 4 days ago while this was just posted today) while, if it is version 4.1.0, providing support on an out-of-date version isn’t really something plugins really look to do as potential bugs could/should be fixed in more recent releases. Are you certain you’re using version 4.1.0? Can you provide anything that WP_DEBUG might report regarding Simple History and/or what the your browser’s web inspector console/network tabs say regarding the request to load the content on the dashboard widget?

That being said, it’s probably worth waiting on updating to the newest version if it’s still version 4.2.0 since that has a larger issue per:

• https://www.ads-software.com/support/topic/fatal-error-4488/
• https://www.ads-software.com/support/topic/php-error-in-lastest-version/
• https://www.ads-software.com/support/topic/fatal-error-4492/

all stating that they’re (including myself) encountering the same fatal error when using 4.2.0 which breaks various parts of one’s site after updating. This also makes me wonder if you’re actually on version 4.2.0 which could explain why you’re having issues (if you actually are on version 4.2.0 & are having these issues, I have a workaround outlined in the first paragraph of https://www.ads-software.com/support/topic/fatal-error-4488/#post-16894036.)

My fix was to take version 4.1.0 of Simple History (available from the dropdown at the bottom of https://www.ads-software.com/plugins/simple-history/advanced/), edit the plugin’s main index.php file to change the version from 4.1.0 to instead be 4.2.0.1 (so the site doesn’t try to re-update to the broken version while not having to disable a site’s auto-updates to account for this one plugin yet allowing for the next version release to be applied via a new version that’s likely 4.2.1 or similar [even if it’s 4.2.0.1 & sites don’t auto-update, that’s fine since 4.2.0 didn’t introduce anything too meaningful & it should be okay to wait for the release after that which it should then update to]) and then distribute that plugin across any/all affected and/or soon to be affected sites to get it out of the way.

I do agree with you, though. I have no idea how a plugin release that’s reportedly being used by 200k+ sites that’s breaking a bunch of aspects of a given website (potentially silently) has gone 4 days after being reported without being fixed (or otherwise taking that problematic version down so no further sites update & break themselves [heck, they could’ve done what I did in taking 4.1.0 and call that a new version to then be served from WP.org until the full fix for 4.2.0 is complete… that approach to stop the spread of this issue would take less than 15 min. to do.]) https://www.ads-software.com/support/topic/php-error-in-lastest-version/#post-16883963 had the developer say they would be fix things today or tomorrow… but that was more than 3 days ago. Not great.

I really like this plugin, but potentially serious issues like this on a release really should be get a faster resolution to the issue than this (even if it’s a stop-gap solution that effectively reverts back to the previous version like I mentioned above since that’s is still better than letting the broken version continue to propagate as more & more sites look to update to the latest version.)

Ah, of course, once I re-post my supplemental info that was removed from the other topic https://www.ads-software.com/support/topic/php-error-in-lastest-version/#post-16883963 has an update regarding this saying a fix will be released today or tomorrow (again, here’s hoping WP can apply that new version release without encountering that error, itself [one would think it wouldn’t be trying to still use the plugin when it’s trying to be updated.])

I’m really thinking that fix should also resolve what I have encountered here, but still having this more info could be helpful nonetheless. ??

Thanks for the update & heads up on the plugin’s release schedule. I’ll keep an eye out for new versions (in about a week or so, it seems) & the changelog to make sure it addresses this bug (user roles get unassigned when editing a user’s profile without having changed the user role when the multiple user roles feature is disabled, or something to that effect.)

Also, if it’d be helpful, let me know if you want me to test the upcoming version of the plugin that has this bug patched to confirm the bug isn’t happening in that new version before release. Otherwise, I trust this bug can be replicated and tested against while also having the proposed fix for reference (since it does kinda just make sense to make sure to not run the multiple user roles logic that’s run on update_profile when multiple user roles are disabled) to have the new version address this properly.

Okay, I think I have a potential fix for this bug.

In features/roles-editor/roles-editor.php around line 1208, change:

function roles_update_user_new_and_edit( $user ) {

    if( ! empty( $_POST['wppb_re_user_roles'] ) ) {

        $old_roles = (array) $user->roles;

        $new_roles = array_map( array( $this, 'sanitize_role' ), $_POST['wppb_re_user_roles'] );//phpcs:ignore  WordPress.Security.ValidatedSanitizedInput.InputNotSanitized

        foreach( $new_roles as $new_role ) {
            if( ! in_array( $new_role, (array) $user->roles ) ) {
                $user->add_role( $new_role );
            }
        }

        foreach( $old_roles as $old_role ) {
            if( ! in_array( $old_role, $new_roles ) ) {
                $user->remove_role( $old_role );
            }
        }
    } else {
        foreach( (array) $user->roles as $old_role ) {
            $user->remove_role( $old_role );
        }
    }

}

to instead be:

function roles_update_user_new_and_edit( $user ) {

    // Check for the "Disable Multiple User Roles" setting so this can know to leave the single role setup alone if "Disable Multiple User Roles" setting is enabled, but then process the multiple user roles form fields as needed if that isn't enabled.
    $wppb_toolbox_admin_settings = get_option( 'wppb_toolbox_admin_settings');
    if(!array_key_exists('multiple-user-roles',$wppb_toolbox_admin_settings)){
        // Make sure the user roles setting check doesn't try looking for a key that might not exist
        $wppb_toolbox_admin_settings['multiple-user-roles'] = false;
    }
    if(!$wppb_toolbox_admin_settings['multiple-user-roles'] || $wppb_toolbox_admin_settings['multiple-user-roles'] != 'yes'){ // If "Disable Multiple User Roles" setting hasn't been set yet (with the default of it not being enabled) or is otherwise enabled (where it has a value of "yes" when enabled), proceed with handling the multiple user role setup.
        if( ! empty( $_POST['wppb_re_user_roles'] ) ) {

            $old_roles = (array) $user->roles;

            $new_roles = array_map( array( $this, 'sanitize_role' ), $_POST['wppb_re_user_roles'] );//phpcs:ignore  WordPress.Security.ValidatedSanitizedInput.InputNotSanitized

            foreach( $new_roles as $new_role ) {
                if( ! in_array( $new_role, (array) $user->roles ) ) {
                    $user->add_role( $new_role );
                }
            }

            foreach( $old_roles as $old_role ) {
                if( ! in_array( $old_role, $new_roles ) ) {
                    $user->remove_role( $old_role );
                }
            }
        } else {
            foreach( (array) $user->roles as $old_role ) {
                $user->remove_role( $old_role );
            }
        }
    }

}

where it effectively checks to make sure anytime the “Disable Multiple User Roles” setting is enabled that it doesn’t then try to use the code that’s only for when the multiple user role setup is actually being used.

Now, this hasn’t been fully tested when multiple user roles are being used on a site since this was needing to be a hot fix for a live site that was experiencing this issue when that site shouldn’t have the multiple user role setup. Also, I’m not 100% familiar with the programming conventions of this plugin, might be overly cautious with checking for that setting, and ultimately just wanted to quickly make ends meet so there might be some adjustments that could be made to the proposed fix.

I’d definitely love to see this patch implemented in the next release of Profile Builder since this was needing to be a patch applied to a live site to fix this active bug, and I’d like to know that this plugin can be updated without having this bug resurface due to it not keeping this fix.

function roles_update_user_new_and_edit( $user ) {

    if( ! empty( $_POST['wppb_re_user_roles'] ) ) {

        $old_roles = (array) $user->roles;

        $new_roles = array_map( array( $this, 'sanitize_role' ), $_POST['wppb_re_user_roles'] );//phpcs:ignore  WordPress.Security.ValidatedSanitizedInput.InputNotSanitized

        foreach( $new_roles as $new_role ) {
            if( ! in_array( $new_role, (array) $user->roles ) ) {
                $user->add_role( $new_role );
            }
        }

        foreach( $old_roles as $old_role ) {
            if( ! in_array( $old_role, $new_roles ) ) {
                $user->remove_role( $old_role );
            }
        }
    } else {
        foreach( (array) $user->roles as $old_role ) {
            $user->remove_role( $old_role );
        }
    }

}

This code snippet from features/roles-editor/roles-editor.php seems curious (especially the last bit of when wppb_re_user_roles doesn’t exist in the $_POST when update_profile is triggered [since this function is called by other PB functions that hook into that action] then loops through and seemingly removes the existing role[s]… for some reason…?) Will be testing different things out.

@shadow772 What error are you being given when using WP_DEBUG and/or Query Monitor (or similar)? Can’t really say what the issue is that you’re having without that as I have sites running those same versions (also having used TEC 6.1.0.2 + ET 5.5.11.1 and upgrading them to 6.1.1 + 5.6.0, respectively [also having various sites with & without The Events Calendar Pro and/or Event Tickets Plus, also latest versions, being thrown into the mix]) and I’m not having a critical error on any of these (it was really just the TEC 6.1.0 and ET 5.5.11.1 that had an issue that was fixed by TEC 6.1.0.2 & subsequent plugin versions.)

The actual error that was confirmed to be happening for this support forum topic has been resolved. As such, if you’re still experiencing issues, you should probably open a new topic (supplying the actual error message from WP_DEBUG/etc. that is very helpful, if not outright needed, to properly identify the issue) to then discuss that different issue as it likely will have a different solution.

@daivernon That issue probably warrants opening a separate support forum topic as that looks to be a different error that will likely have a different solution. The issue here has been fixed per the updated The Events Calendar 6.1.0.2 version release (and therefore has been marked as resolved while your issue may need additional attention in a separate topic for that issue.)

Marking this topic as resolved as it looks like the particular issue involved here has been addressed with The Events Calendar 6.1.0.2 (resolving the conflict that The Events Calendar 6.1.0 introduced with Event Tickets 5.5.11.1.)

It looks to be working now. Thanks for the update!

@gugaalves Thanks for the update! Looking forward to the official fix to be released. ??

@gugaalves Thanks for the update! Looking forward to the official fix to be released. ??

@jrthor2 Again, I just went with that one-line hotfix edit of event-tickets/src/Tribe/Integrations/Freemius.php on line 136 so that $should_load = false; since I don’t want to place a filter on the site that might last longer than it needs to when one would imagine that the next version of The Events Calendar and/or Event Tickets fixes this error formally so just updating, while potentially overwriting the hotfix, will have this issue go away (one would imagine this would be doable & would be the ideal fix since a custom code edit to add a filter to manually disable Freemius in Event Tickets on various sites affected by this [of which are using software versions that should be fully supported & work properly] to then avoid a fatal server error just doesn’t make sense as something that’s still needed after the next version release[s].)

As an aside, I’ve cross-posted this at https://www.ads-software.com/support/topic/event-tickets-5-5-11-1s-freemius-causing-errors-with-the-events-calendar-6-1-0/ since this might apply to Event Tickets just as much (if not more) than The Events Calendar when it comes to what needs to be updated to address the fatal server error that’s happening between the latest versions of these two plugins.