Forum Replies Created

Viewing 15 replies - 1 through 15 (of 26 total)
  • Thread Starter Boldair Développement

    (@boldairdeveloppement)

    Hi :
    the steps are simple :

    install and activate the plugin
    go to the page for the user accounts
    the search box on top right is hidden,

    deactivate the plugin : it reappears

    the code that triggers this is in the popup-builder/com/classes/Actions.php, line 216 :

    public function showPreviewButtonAfterPopupPublish()
    	{
    		$currentPostType = AdminHelper::getCurrentPostType();
    		if (!empty($currentPostType) && ($currentPostType == SG_POPUP_POST_TYPE || $currentPostType == SG_POPUP_AUTORESPONDER_POST_TYPE || $currentPostType == SG_POPUP_TEMPLATE_POST_TYPE)) {
    			echo '<style>
    				#save-post {
    					display:none !important;
    				}
    				.subsubsub {
    					display:none !important;
    				}
    				.subsubsub.show {
    					display:block !important;
    				}
    				.search-box {
    					display:none !important;
    				}
    				.search-box.show {
    					display:block !important;
    				}
    				.tablenav-pages.no-pages {
    				    display: block;
    				}
    				.tablenav-pages *:not(.subsubsub, .subsubsub *),
    				.tablenav-pages.no-pages *:not(.subsubsub, .subsubsub *),
    				.tablenav-pages.one-page *:not(.subsubsub, .subsubsub *) {
                        display: none;
                    }
    			</style>';
    		}
    	}

    the reason why it’s triggerred is that
    the variable $currentPostType is set to ‘popupbuilder’ on the accounts (users) page when $currentPostType = AdminHelper::getCurrentPostType(); is called
    (I checked its value by echoing it there)

    Possibly because comments and user accounts (the function is triggerered on the comments lists too) are not post types and getCurrentPostType() falls back to a default value of ‘popupbuilder’ when it does not find a post-type value.

    I haven’t checked but maybe doing something like :

    if (!is_object($post)) {
    			return '';
    		}

    as a first thing in popup-builder/helpers/AdminHelper.php in the getCurrentPostType() function could correct the problem

    Thread Starter Boldair Développement

    (@boldairdeveloppement)

    Hi,

    Here is the link with the system info : https://we.tl/t-1aDYuYMLen
    (sorry I was away on friday, just saw this now)

    Thread Starter Boldair Développement

    (@boldairdeveloppement)

    Hello @abishek

    Well I can’t say I’m surprised by that reply, even though in this instance it’s not my host provider.

    To give you some context, my customer is a subsidy of a big french publisher, that publisher has an internal IT service that acts as the host provider for the entire corporation.

    My customer are contractually obligated to use them instead on any other hosting service. They also charge my customer hefty fees for about anything, be it the hosting or changing a slash in a virtual host configuration file (they did that just last wee in fact, I’m not kidding, there was a misspelling or a ‘//’, instead of ‘://’ in a Content-Security-Policy, they charged something like 5 hours for the correction)

    And this IT service has flat out refused to change the PHP version on this server. It’s not ‘Give us a good reason, and we will charge you but we will do it’, it’s ‘No way ever will it happen good sir’.

    I’ve had dozens of headbutting with these guys other the years, but they just don’t budge, even when so obviously wrong.

    So I’ve been living in dread of the day where the PHP 5 compatibility would finally be broken on these 9 sites by some plugin or other, because I cannot change hosting on them, and I cannot have the server’s PHP upgraded.

    Turns out its the theme with 5 lines to show off how good and nifty the coder who wrote them is, but that have not any real benefit to the efficiency of the theme itself. Well that was bound to happen sooner or later. I’m finally caught between a rock and a hard place and bout to be crushed 🙂

    Now i will have to disable the updates on those themes on the sites, crossing fingers that they don’t have some XSS vulneralbility in the latest working version, and hope for the best.

    Well thanks for you time anyway.

    Hi,

    there is a way to patch the file that causes the problem see my post in this topic :
    https://wordpress.org/support/topic/php-warning-strtotime-expects-parameter-2-to-be-integer-string-given-in-wp/

    We are all waiting for the official update, but if you can’t, this is the way to do it

    (additionally you have to apply the same patch to line 786 and next, I forgot to mention in in the post and couldn’t edit it afterwards)

    If you can’t wait for an official fix here is my solution :

    Line 205 replace :

    $range_start 	= date( 'Hi', strtotime( '-30 minutes', $updateSched) );
    $range_end 		= date( 'Hi', strtotime( '+30 minutes', $updateSched) );

    with :

    $update_time 	= wp_next_scheduled( 'wp_update_plugins' );
    $range_start 	= date( 'Hi', strtotime( '-30 minutes', $update_time ) );
    $range_end 		= date( 'Hi', strtotime( '+30 minutes', $update_time ) );

    and line 316 replace :

    // Check manual or automatic
    $range_start 	= date( 'Hi', strtotime( '-30 minutes', $updateSched) );
    $range_end 		= date( 'Hi', strtotime( '+30 minutes', $updateSched) );

    With :

    // Check manual or automatic
    $update_time 	= wp_next_scheduled( 'wp_version_check' );
    $range_start 	= date( 'Hi', strtotime( '-30 minutes', $update_time ) );
    $range_end 		= date( 'Hi', strtotime( '+30 minutes', $update_time ) );

    that’s what is done already for the themes updates check on line 263. I think the use of $updateSched as the second parameter might have be an oversight (or more likely a copy paste from lines 563 and later where the code goes like this :

    
    $updateSched 	= wp_next_scheduled( 'wp_update_plugins' );
    $range_start 	= date( 'Hi', strtotime( '-30 minutes', $updateSched ) );
    $range_end	= date( 'Hi', strtotime( '+30 minutes', $updateSched ) );
    

    Same error, same cause..

    lines 204, 205, 316, 317 for me 🙂

    a fix would indeed be most welcome, my log files will thank you 🙂

    I got the new addon-version, they are working excepted :

    wpsso-um is still broken (v3.4.0, no 3.4.1 reported yet), It’s less critical though

    Update Manager for the WPSSO Core Premium plugin and its Premium complementary add-ons.
    Version 3.4.0 | Par JS Morisset | Aller sur le site de l’extension
    
    Cette extension n’a pas pu se charger correctement et a été mise en pause dans le cadre du mode de récupération.
    
    Une erreur de type E_ERROR a été causée dans la ligne 71 du fichier /home/parisbas/www/wp-content/plugins/wpsso-um/wpsso-um.php. Message d’erreur : Uncaught ArgumentCountError: Too few arguments to function WpssoUm::init_objects(), 1 passed in /home/parisbas/www/wp-includes/class-wp-hook.php on line 289 and exactly 3 expected in /home/parisbas/www/wp-content/plugins/wpsso-um/wpsso-um.php:71 Stack trace: #0 /home/parisbas/www/wp-includes/class-wp-hook.php(289): WpssoUm->init_objects(true) #1 /home/parisbas/www/wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters(NULL, Array) #2 /home/parisbas/www/wp-includes/plugin.php(478): WP_Hook->do_action(Array) #3 /home/parisbas/www/wp-content/plugins/wpsso/wpsso.php(461): do_action('wpsso_init_obje...', true, false, false) #4 /home/parisbas/www/wp-includes/class-wp-hook.php(287): Wpsso->set_objects('') #5 /home/parisbas/www/wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters(NULL, Array) #6 /home/parisbas/www/wp-includes/plugin.php(478): WP_Hook->do_action(Array) #7 /home/parisbas/www/wp-settings.php(546): do_action('init') #8 /home/parisbas/www/wp-config.php(113): require_once('/home/parisbas/...') #9

    Hi, I was coming to complain about the same error, you beat me to it :)I’ve the same error, and it’s not only on this extension but on ALL wp sso add-ons that have been updated today.

    I have about a dozen+ broken sites resultings from this.

    I suspect the ‘Refactored the add-on class to extend a new WpssoAddOn abstract class.’ part of today’s update is the one responsible

    Oh and YES i use automatic plugin updates… I’m trusting like that 🙂

    Thread Starter Boldair Développement

    (@boldairdeveloppement)

    Hi,
    Well I hadn’t my hopes up on that one, but you never now, you could have had the perfect reply in the style of ‘Oh of course I’ve seen this before and this is why it’s happening:’

    And yes I have a dev site, and yes it’s probably some conflict, at some level, the thing is debugging that is not going to be a fun ride.

    Anyhow thanks for your reply, it at least helps to eliminate CPT UI as the cause 🙂

    Thanks for updating that fast.

    Nonetheless I’ve go 40+ sites that have been broken due to this (an still are, I’m manually correcting at the moment (not all are sending me recovery mode, due to older hosting/wp versions). All my sites are using auto updates for plugins, to keep abreast of fixes and security features 🙁

    Thread Starter Boldair Développement

    (@boldairdeveloppement)

    Hello.
    So I contacted the Wordfence team about this and that was their reply :

    Hi,

    The WPSSO Core (The Complete Meta Tag and Schema Markup Solution) plugin author is not managing their code properly at the plugin repository.

    See the 7.8.0 version tag below:

    https://plugins.trac.wordpress.org/browser/wpsso/#tags/7.8.0

    You will see multiple different modification dates for files for version 7.8.0 of the plugin.

    Each time a plugin author makes a change to any file they should release a new tag version number. The only file changes that a Standard Wordfence scan will ignore is for TXT text files. Any changes to other files for the same version tag number will result in modified file scan results.

    Kind regards,

    Phil
    Customer Support Engineer

    So I suppose this is the source of the discrepancies I’m seeing (and the Wordfence alerts). It’d be nice if you revised your updates process, but if not, I’ll live with it 😉

    Have a great day.

    Thread Starter Boldair Développement

    (@boldairdeveloppement)

    Hi, Thanks for your reply. I can of course exclude WPSSO, still it’s a risk, because if a malicious change did happen in those plugins I wouldn’t be warned about it.

    I guess I’ll take the question to the Wordfence team (who in turn might then have questions for you about the flow and source of changes on your plugins)

    Have a nice day 🙂

    Actually it’s a CSS rule that is the issue:

    input[type=”checkbox”], input[type=”radio”] {

    -webkit-appearance: none;
    -moz-appearance: none;

    }

    if you deactivate those in the dev console, the checkboxes will be usable (I sent a bug report to the developer. Hopefully there will be a patch soon

    Thread Starter Boldair Développement

    (@boldairdeveloppement)

    @sterndata Thanks for your quick reply. I can now report to my client that those js libraries have been correctly patched with a reference towards the patch 🙂

    Thread Starter Boldair Développement

    (@boldairdeveloppement)

    Hi,

    I saw you updated WPSSO to version 6.21.1 in order to remove the nagger, thanks for that.

    Have a good day 🙂

Viewing 15 replies - 1 through 15 (of 26 total)