DeveloperWil

I’m in the process of building a staging clone of the production site to test this.

Production has 1,000’s of active users 24/7 so I can’t just go disabling plugins!

Thanks,
Wil.

I can verify that the plugin does not work on WordPress 6.0.x

Confirmed the fix works.

Plugin author can you please apply a fix?

Wil.

I am having the same issue.

Can you please add a URL-based whitelist option so we can whitelist the REST API endpoints.

Could not load content for https://mydomain.com/wp-content/plugins/wp-menu-icons/assets/css/admin.css.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

This is a nonsensical restriction by the repo admin team.

Pretty much all plugins restrict features unless a pro license is purchased, including Automattic’s own Jetpack plugin.

There is no mention of the word “trial” or even the idea of a trial for the free version.

It works as-is with a 10 folder limit (not a trial), limit.

The free plugin does not expire as you would expect a trial to do.

Leaving 3,000+ active users in limbo because of a bad interpretation is a bad failure of management.

@marcoatmac What do you mean? Change the vendor of multiple products?

I always run the current versions so Version 2.4.7.

Open up a new post or an existing post for editing and the error message appears towards the top left of the screen.

False positive – it was a caching issue with Siteground.

Sorry to bother you and thanks for the quick response!

Can’t edit any menu items with Elementor

Can’t edit the mega menu in elementor – no menu settings when opening in elementor.
There is a JS error:
elementor.config.settings.pageis soft deprecated since 2.9.0 - Useelementor.config.document.settings` instead

Hi @sanjaydabhoya

Figured out the reason was that the PHP lib SimpleXML had not been installed on the server.

Everything working fine again.

Regards,
Wil.

Same issue here but only if you have something in the Notes field and leave your browser tab open in edit mode for 15-30 mins.

Having installed New Relic on the server to see why there is a huge resource uptake, I’ve found that session_start() is taking between 11 and 12 seconds to initiate.

Because these are run through admin-ajax.php, they are effectively locking the PHP script from continuing, resulting in high memory usage and a timeout of the Apache child threads.

This has been confirmed in these threads:
https://stackoverflow.com/questions/13772074/session-start-takes-very-long-time
https://konrness.com/php5/how-to-prevent-blocking-php-requests/

— SNIP —
Problem
PHP writes its session data to a file by default. When a request is made to a PHP script that starts the session (session_start()), this session file is locked. What this means is that if your web page makes numerous requests to PHP scripts, for instance, for loading content via Ajax, each request could be locking the session and preventing the other requests from completing.

The other requests will hang on session_start() until the session file is unlocked. This is especially bad if one of your Ajax requests is relatively long-running.

Solution
The session file remains locked until the script completes or the session is manually closed. To prevent multiple PHP requests (that need $_SESSION data) from blocking, you can start the session and then close the session. This will unlock the session file and allow the remaining requests to continue running, even before the initial request has completed.
— END SNIP —

I have modified the file
share-logins\includes\functions.php
line 181:

if( ! function_exists( 'cx_set_scheduled_urls' ) ) :
function cx_set_scheduled_urls( $urls ) {
    $_SESSION['_share-logins_scheduled_urls'] = base64_encode( serialize( $urls ) );
    // ZPD 23/11/2019 - close the session
    session_write_close();
}
endif;

share-logins-pro\includes\functions.pgp
line: 149

if( ! function_exists( 'cx_set_scheduled_urls' ) ) :
function cx_set_scheduled_urls( $urls ) {
    $_SESSION['_share-logins_scheduled_urls'] = base64_encode( serialize( $urls ) );
    // ZPD 23/11/2019 - close the session
    session_write_close();
}

To write close the session leaving it available to read.

Ultimately it would work a lot faster if they were being stored in the DB.

Regards,
Wil.

Hi @codexpert

I have just run a code diff on 2.1.1 and 2.1.2 and the only difference I can see is that you are setting the remember parameter for wp cookies to true.

This is not addressing the larger issue of the PHP sessions that you create in the /includes/Schedule/Schedule.php __construct() method.

Nowhere in the code do you use session_destroy() to delete these php sessions which are running in each Apache child thread.

Here is my amended code which seems to help the issue – notice I check to see if there are any scheduled URLs still to run and if not I destroy the created PHP session.

<?php
/**
 * All trigger facing functions
 */

namespace codexpert\Share_Logins;

/**
 * if accessed directly, exit.
 */
if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

/**
 * @package Plugin
 * @subpackage Schedule
 * @author Nazmul Ahsan <[email protected]>
 */
class Schedule extends Hooks {

    /**
     * Constructor function
     */
    public function __construct( $plugin ) {
        $this->name     = $plugin['Name'];
        $this->ncrypt   = ncrypt();
        if ( session_status() == PHP_SESSION_NONE ) {
            session_start();
        }
    }

    public function run() {
        $_scheduled_urls = cx_get_scheduled_urls();
        if( is_array( $_scheduled_urls ) && count( $_scheduled_urls ) > 0 ) :

		foreach ( $_scheduled_urls as $url ) {
			echo "<script src='{$url}'></script>";

            if( defined( 'CXSL_DEBUG' ) && CXSL_DEBUG ) {
                @parse_str( $url );
                cx_add_log( 'trigger', 'outgoing', $this->ncrypt->decrypt( $user_login ), cx_get_route_home( $url ) );
            }
		}

        cx_clean_scheduled_urls();
        endif;
        // ZPD 21/10/2019 - destroy session if scheduled URLs are empty
        if( empty( cx_get_scheduled_urls() ) ) {
            session_destroy();
        }
    }
}

Can you please pass this feedback to the developers and ask them to properly destroy PHP sessions that they are creating. It is causing a huge memory and php issue on my client’s server.

The issue is critical to the point where we are now being forced to consider alternaitve SSO plugins.

I’m happy to work with your devs in resolving this issue. You can find me at https://github.com/DeveloperWil

Regards,
Wil.