Forum Replies Created

Viewing 15 replies - 1 through 15 (of 104 total)
  • Thread Starter Antony Booker

    (@antonynz)

    Thanks for the reply. That directory only has the font files for FontAwesome.

    I searched through the plugin and found the Lato font file here:
    nextgen-gallery\products\photocrati_nextgen\modules\nextgen_admin\static\Lato-Regular.ttf

    Would you be able to update the link within the plugin’s stylesheet above to that location? or remove that font reference if it’s not required? as its currently returning a 404 error in the block editor.

    Thread Starter Antony Booker

    (@antonynz)

    Thanks for the quick reply. Having the disable option is great but would it be possible to remove the brands font family reference from the FA stylesheets in the plugin as font awesome is often used on the sites.

    As the plugin doesn’t include the brand font files but declares the font family some browsers may try to download the brand fonts from this plugin but the files will be missing.

    Thread Starter Antony Booker

    (@antonynz)

    I wasn’t able to replicate the sitemap issue. However the function and that file is the same from what I can see? As it’s called within wp_enqueue_scripts it might have unexpected problems and conflicts.

    The two issues are:
    1. content echo’d in wp_enqueue_scripts
    2. wp_print_inline_script_tag used incorrectly with an “echo” in front

    Something like this would be more suitable if you are wanting to output javascript variables to the page when loading a javascript file:

    public function load_inline_script() {
    $script_handle = 'your-main-script-handle'; // Replace with the handle of your enqueued script

    $js_inline = '
    var theplus_ajax_url = "' . admin_url("admin-ajax.php") . '";
    var theplus_ajax_post_url = "' . admin_url("admin-post.php") . '";
    var theplus_nonce = "' . wp_create_nonce("theplus-addons") . '";
    ';

    wp_add_inline_script($script_handle, $js_inline);
    }

    Or if only the inline script is needed the script could be loaded using the wp_head action:

    public function load_inline_script() {
    add_action('wp_head', function() {
    ?>
    <script type="text/javascript">
    var theplus_ajax_url = "<?php echo esc_url(admin_url('admin-ajax.php')); ?>";
    var theplus_ajax_post_url = "<?php echo esc_url(admin_url('admin-post.php')); ?>";
    var theplus_nonce = "<?php echo esc_js(wp_create_nonce('theplus-addons')); ?>";
    </script>
    <?php
    });
    }

    Thread Starter Antony Booker

    (@antonynz)

    Thanks for the quick patch. The rest api endpoints are responding again..

    Thread Starter Antony Booker

    (@antonynz)

    Thanks for the reply.

    The bottleneck appears to be when “ORDER BY meta_id ASC;” is in the query with the high performance keys which results in a high creating sort time.

    Here is a profile of the query with high performance indexes on the postmeta table taking .13s:

    Duration: 0.13756471s

    Starting: 0.000143s
    checking permissions: 0.000006s
    Opening tables: 0.000009s
    After opening tables: 0.000007s
    System lock: 0.000004s
    table lock: 0.000005s
    init: 0.000080s
    Optimizing: 0.000033s
    Statistics: 0.000248s
    Preparing: 0.000017s
    Sorting result: 0.000006s
    Executing: 0.000004s
    Sending data: 0.000006s
    Creating sort index: 0.136885s
    End of update loop: 0.000020s
    Query end: 0.000004s
    Commit: 0.000004s
    Query end: 0.000004s
    closing tables: 0.000004s
    Unlocking tables: 0.000004s
    closing tables: 0.000005s
    Query end: 0.000005s
    Starting cleanup: 0.000004s
    Freeing items: 0.000016s
    Updating status: 0.000013s
    Logging slow query: 0.000024s
    Reset for next command: 0.000006s
    ALTER TABLE wp_postmeta
    ADD PRIMARY KEY (post_id,meta_key,meta_id),
    ADD UNIQUE KEY meta_id (meta_id),
    ADD KEY meta_key (meta_key,meta_value(32),post_id,meta_id),
    ADD KEY meta_value (meta_value(32),meta_id);
    Postmeta rows: 2,019,801 461.4 MiB	

    And a profile with the standard indexes taking .05s

    Query ID: 1 Duration: 0.05160964s

    Starting: 0.000139s
    checking permissions: 0.000006s
    Opening tables: 0.000009s
    After opening tables: 0.000006s
    System lock: 0.000005s
    table lock: 0.000005s
    init: 0.000084s
    Optimizing: 0.000035s
    Statistics: 0.000251s
    Preparing: 0.000027s
    Sorting result: 0.000006s
    Executing: 0.000004s
    Sending data: 0.000006s
    Creating sort index: 0.050946s
    End of update loop: 0.000019s
    Query end: 0.000005s
    Commit: 0.000004s
    Query end: 0.000004s
    closing tables: 0.000004s
    Unlocking tables: 0.000004s
    closing tables: 0.000004s
    Query end: 0.000005s
    Starting cleanup: 0.000004s
    Freeing items: 0.000015s
    Updating status: 0.000009s
    Reset for next command: 0.000006s
    ALTER TABLE wp_postmeta
    ADD PRIMARY KEY (meta_id),
    ADD KEY post_id (post_id),
    ADD KEY meta_key (meta_key(191));
    Postmeta rows: 1,759,255 294.0 MiB

    Could the longer times simply be from the larger database size with the extra indexes?

    Thread Starter Antony Booker

    (@antonynz)

    Thanks for the quick reply. I’d recommend reinstating the filter or if it’s no longer applicable adding a deprecated code message if the filter is added.

    Looks like it adds the script to any file in the theme that has functions in the filename. I’d recommend restoring a backup of the themes folder or searching the folder for “my_admin_init_function_run” to remove that code.

    You’ll need to manually check the functions.php file in the theme (usually under wp-content/themes/yourtheme/functions.php and remove the suspicious code, such as with a file manager in the hosting control panel or by using FTP.

    The injected code will look like this at the top of the functions.php file:

    if (!function_exists('add_footer_script')) {
    function add_footer_script() {
    update_option('my_admin_init_function_run', 'yes');
    echo '<script>eval(......);</script>';
    }
    $has_run = get_option('my_admin_init_function_run');
    if ($has_run !== 'yes') {
    add_action('wp_footer', 'add_footer_script');
    }
    }
    Thread Starter Antony Booker

    (@antonynz)

    @benzoid glad you were able to regain access quickly.

    There seems to be some confusion, to confirm the issue is with the code added in the patched version 11.9.7 by the plugin review team that loops through and finds vulnerable administrator usernames, that had been added in previous versions.

    Specifically the get_users?function which is looping through all users in the PowerPress_PRT_incidence_response function. This could be changed to loop through admin users only to prevent high cpu usage on sites with lots of users.

    Thread Starter Antony Booker

    (@antonynz)

    Yes this code is in the force updated version from, 11.9.7 that checks for vulnerable usernames.

    Thread Starter Antony Booker

    (@antonynz)

    Thanks for the response. Those snippets relate to changing cron jobs, however forminator uses the action scheduler instead:

    /**
     * Set up the schedule
     *
     * @since 1.0
     * @since 1.27 Change from WP cron to Action Scheduler
     */
    public function schedule_entries_exporter() {
        // Clear old cron schedule.
        if ( wp_next_scheduled( 'forminator_send_export' ) ) {
            wp_clear_scheduled_hook( 'forminator_send_export' );
        }
    
        // Create new schedule using AS.
        if ( false === as_has_scheduled_action( 'forminator_send_export' ) ) {
            as_schedule_recurring_action( time() + 10, MINUTE_IN_SECONDS, 'forminator_send_export', array(), 'forminator', true );
        }
    }

    This is triggering an action scheduler http request every minute.

    I couldn’t find a similar filter for changing the action scheduler task frequency.

    Do those tasks need to run every minute? especially for the forminator_process_report hook as only hourly can be selected in the backend for report notifications. I’ll keep investigating if there’s a way to remove the extra requests.

    Thread Starter Antony Booker

    (@antonynz)

    Thanks for the reply.

    The external request to the sift URL is found within the admin_print_footer_scripts action in the woocommerce-services\woocommerce-services.php file on line #897:
    add_action( ‘admin_print_footer_scripts’, array( $this, ‘add_sift_js_tracker’ ) );

    This will load the “add_sift_js_tracker” function on every admin page which then requests https://api.woocommerce.com/payment/sift

    This can be seen below in the add_sift_js_tracker function which calls “get_sift_configuration” that makes the HTTP request to the woocomerce.com/payment/sift URL

        public function add_sift_js_tracker() {
            $sift_configurations = $this->api_client->get_sift_configuration();
    
        public function get_sift_configuration() {
            return $this->request( 'GET', '/payment/sift' );
        }

    Looking at the changelog for this plugin I can see that Sift was added for printing labels? I’m not sure where the print label function is used. Would this need to be loaded on every admin page?

    2.3.7 – 2023-10-23 =
    * Add – Load Sift when printing a label.

    Here is a tool to see the response time of that request from around the world:
    https://tools.keycdn.com/performance?url=https://api.woocommerce.com/payment/sift

    From Sydney it’s taking .74s to respond . This adds .74s to the backend page generation whilst WordPress waits for the request to finish.

    • This reply was modified 9 months, 2 weeks ago by Antony Booker.
    Thread Starter Antony Booker

    (@antonynz)

    Sorry for the confusion. I’m not requesting any custom code as I can code this per site. But hopefully it will be possible to get this plugin compatible with the relevanssi search plugin in general for other sites.

    Currently when both plugins are installed draft statuses show in search results due to how the relevanssi plugin checks if a user can access a post in Simple Membership using the can_i_read_post function.

    Other membership plugins have similar filters to check if a user should have access to a post that isn’t in a draft/private status, however using the can_i_read_post it doesn’t check if a post is published or not. Should the can_i_read_post function be set to check that?

    I have reached out to Relevanssi regarding this but they couldn’t say why the SM plugin did this. If this isn’t a suitable filter to use in general for other plugins I can reach out to Relevanssi again to recommend they change their code to prevent draft posts showing in search results.

    Thread Starter Antony Booker

    (@antonynz)

    Thanks for the correction, it was running but yes you’re right it should be add_action and wouldn’t need the post returned. I have added it below in case other users may wish to use it:

    add_action('the_post','filter_content_post', 999, 1);
    function filter_content_post($post){
    	if (!class_exists('SimpleWpMembership')) {
    		return $post;
    	}
    
        if (is_preview() || is_admin()) {
            //If the user is logged-in as an admin user then do not apply filtering for admin side viewing or preview page viewing.
            if ( current_user_can('administrator') ){
                //The user is logged in as admin in this browser.
                return $content;
            }
        }
        $acl = SwpmAccessControl::get_instance();
    	$content = $post->post_content;
        $post->post_content = $acl->filter_post($post, $content);
    }
    Thread Starter Antony Booker

    (@antonynz)

    Thanks for the reply the Force user synchronization option seems to address the issue and logs out the user when the WP logged in cookie has expired. Bit of an odd set up I think that should be enabled by default to prevent caching conflicts.

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