Forum Replies Created

Viewing 12 replies - 1 through 12 (of 12 total)
  • Thread Starter markc369

    (@markc369)

    I am on Version 1.5.2 (Free version).

    I do not remember seeing the problem a few versions back…but then I normally just install to my local XAMPP server and that moans but carries on. It was only when installing on a live hosting that it fell over completely.

    Thanks,

    Thread Starter markc369

    (@markc369)

    Thank you for getting back to me.

    I will continue to see if the theme provider can provide a fix, but if not, then I will consider your suggested fix.

    Or I might have to opt for another plugin – don’t really want to waste more time. ??

    Many thanks and really appreciate your help.

    Mark.

    Thread Starter markc369

    (@markc369)

    Thanks for getting back to me and for letting me know that this is the problem.

    It seems to be being added by the actual them that I am using, rather than another plugin, so I have contacted their support to see what they say.

    If this is something that they cannot / will not change, is there a fix that you might be able to recommend?

    Thanks again for all your help.

    Mark.

    Thread Starter markc369

    (@markc369)

    Thanks for getting back to me.

    Here is the link for the Purge Front Page Button (When I hover over it).

    https://www.cafedelmarydelsol.com/wp-admin/admin.php?page=litespeed-toolbox&post_type=post&LSCWP_CTRL=purge&LSCWP_NONCE=7a20bca604&litespeed_type=purge_frontpage

    The result of clicking on the button is:

    Cannot load litespeed-toolbox.

    When I compare the sample that you sent and my own, I do note that there is an extra query string “post_type=post” which is not in yours – could this be relevant?

    Thank you.

    Hi,

    Here is further information regarding the reported issue.

    As stated before, the problem arises when another plugin or theme manipulates the query and sets the post_type to be an array containing multiple post_type values.

    Following on from what @psyhonet had reported, I tested the case with Rank Math SEO, Yoast DP and Elementor (Theme in this case not relevant) and was able to reproduce the error. I can see the @tacoverdo responded but was unable to recreate the issue – but without Elementor, you will not see it as the problem is specific to recreation of the post list when Elementor is active.

    In this case the problematic function was here:

    wp-content\plugins\seo-by-rank-math\includes\replace-variables\class-base.php

    /**
        * Get post <code>object</code>.
        *
        * @return WP_Post
        */
    protected function get_post() {
        if ( isset( $this->post ) ) {
            return $this->post;
        }
    
        $this->post = get_post( Post::is_shop_page() ? Post::get_shop_page_id() : null );
    
        if ( is_null( $this->post ) ) {
            $posts      = get_posts(
                [
                    'fields'         => 'id',
                    'posts_per_page' => 1,
                    'post_type'      => [ 'post', 'page' ],
                ]
            );
            $this->post = isset( $posts[0] ) ? $posts[0] : null;
        }
    
        if ( is_null( $this->post ) ) {
            $this->post = new \WP_Post(
                (object) [
                    'ID'         => 0,
                    'post_title' => __( 'Example Post title', 'rank-math' ),
                ]
            );
        }
    
        return $this->post;
    }

    As you can see, post_type is set here to an array containing ‘post’ and ‘page’. The query filters set by Yoast are being applied to the updated query and failing to handle the post_type as an array.

    Equally, in the Rife Free theme, a similar situation occurs, but in this case it is within the Theme, not a plugin. The problematic function was here:

    wp-content\themes\rife-free\advance\class-apollo13-framework.php

    /**
    * Function for warnings that should be displayed in admin area
    */
    function check_for_warnings()
    {
        $notices = array();
        $valid_tags = array(
            'a' => array(
                'href' => array(),
            ),
        );
        // Notice if dir for user settings is no writable
    
        //NOTICE IF CPT SLUG IS TAKEN
        // albums
        $r = new WP_Query(array('post_type' => array('post', 'page'), 'name' => A13FRAMEWORK_CUSTOM_POST_TYPE_ALBUM_SLUG));
        if ($r->have_posts() && strlen(A13FRAMEWORK_CUSTOM_POST_TYPE_ALBUM_SLUG) && defined('A13FRAMEWORK_CUSTOM_POST_TYPE_ALBUM')) {
            $post_type_details = get_post_type_object( A13FRAMEWORK_CUSTOM_POST_TYPE_ALBUM );
            /* translators: %1$s: Post type name, %2$s: URL */
            $notices['albums-slug'] = sprintf( __( 'Warning - slug reserved for %1$s post type is used by some post or page. It may cause problems with reaching some of your content. You should change slug of <a href="%2$s">this post</a> to make sure everything will work proper.', 'rife-free' ), $post_type_details->label, esc_url( site_url( '/' . A13FRAMEWORK_CUSTOM_POST_TYPE_ALBUM_SLUG ) ) );
        }
        // Reset the global $the_post as this query have stomped on it
        wp_reset_postdata();
    
        // works
        $r = new WP_Query(array('post_type' => array('post', 'page'), 'name' => A13FRAMEWORK_CUSTOM_POST_TYPE_WORK_SLUG));
        if ($r->have_posts() && strlen(A13FRAMEWORK_CUSTOM_POST_TYPE_WORK_SLUG) && defined('A13FRAMEWORK_CUSTOM_POST_TYPE_WORK')) {
            $post_type_details = get_post_type_object( A13FRAMEWORK_CUSTOM_POST_TYPE_WORK );
            /* translators: %1$s: Post type name, %2$s: URL */
            $notices['works-slug'] = sprintf( __( 'Warning - slug reserved for %1$s post type is used by some post or page. It may cause problems with reaching some of your content. You should change slug of <a href="%2$s">this post</a> to make sure everything will work proper.', 'rife-free' ), $post_type_details->label, esc_url( site_url( '/' . A13FRAMEWORK_CUSTOM_POST_TYPE_WORK_SLUG ) ) );
        }
        // Reset the global $the_post as this query have stomped on it
        wp_reset_postdata();
    
        // Display all error notices
        foreach ($notices as $id => $notice) {
            //show notice only if it wasn't dismissed by user
            if( !apollo13framework_is_admin_notice_active($id) ){
                continue;
            }
            echo '<div class="a13fe-admin-notice notice notice-error is-dismissible" data-notice_id="'.esc_attr($id).'"><p>' . wp_kses( $notice, $valid_tags ) . '</p></div>';
        }
    
        do_action( 'apollo13framework_theme_notices' );
    }

    Again, you can see that the query is being altered and the post_type is being set to an array. There is an attempt to reset the query after it has been altered, but this is after the Yoast filters have been applied – hence the problem is not resolved by this.

    The problematic Yoast code is here:

    wp-content\plugins\duplicate-post\src\ui\class-post-list.php

    public function filter_rewrite_and_republish_copies( $query ) {
        if ( ! $this->should_filter() || ( $query instanceof \WP_Query === false ) ) {
            return $query;
        }
    
        $post_not_in = $query->get( 'post__not_in', [] );
        $post_not_in = array_merge( $post_not_in, \array_keys( $this->get_copy_ids( $query->get( 'post_type' ) ) ) );
    
        $query->set( 'post__not_in', $post_not_in );
    
        return $query;
    }

    The above function is trying to call get_copy_ids (below), passing it the post_type value, but it passes an array instead.

    protected function get_copy_ids( $post_type ) {
        global $wpdb;
    
        if ( empty( $post_type ) ) {
            return [];
        }
    
        if ( \array_key_exists( $post_type, $this->copy_ids ) ) {
            return $this->copy_ids[ $post_type ];
        }
    
        $this->copy_ids[ $post_type ] = [];
    
        $results = $wpdb->get_results(
            $wpdb->prepare(
                'SELECT post_id, post_status FROM ' . $wpdb->postmeta . ' AS pm ' .
                'JOIN ' . $wpdb->posts . ' AS p ON pm.post_id = p.ID ' .
                'WHERE meta_key = %s AND post_type = %s',
                '_dp_is_rewrite_republish_copy',
                $post_type
            ),
            OBJECT_K
        );
    
        if ( \is_array( $results ) ) {
            $this->copy_ids[ $post_type ] = $results;
        }
    
        return $this->copy_ids[ $post_type ];
    }

    The get_copy_ids function cannot handle the array as it tries to look up records of posts or pages that are rewrite/republish based on the passed post_type – the query fails. Also the array_key_exists cannot handle the post_type array being passed to it.

    This issue will happen for any themes or plugins that set post_type to an array so I would think that it should be updated here to handle that eventuality…

    I am not a WordPress expert, but I hope that helps,

    Mark.

    Hi,

    I did add a response to the previous thread that this was raised on. Here is what I have so far.

    I did a clean install of WP5.6 (on PHP7.4.13).

    I then installed the following plugins only!
    Elementor 3.0.16
    Yoast DP 4.0.2

    Using the default 2021 theme all is well and there are no problems.

    I then installed the Rife Free theme (just the basic theme).

    After this I could see the problem with the error coming from the “Filter out Rewrite & Republish” function.

    I cannot quite get down to the reason why, but this is what I have at the moment:

    I did a print_r at various points in the function and found that the problem was:

    $query->get( ‘post_type’ )

    When working, this returns the correct post type (be it page or post etc). I also noted that the value is returned only once. this is what I get on a working theme:

    print_r returned : page

    When using the Rife Free theme, this function is called 4 times – the first was correct, the second was another cpt, but the next two outputs were incorrect and were arrays.

    print_r returned : page
    print_r returned : nava
    print_r returned : Array ( [0] => post [1] => page )
    print_r returned : Array ( [0] => post [1] => page )

    This in turn breaks the get_copy_ids function as it is not expecting an array and hence the warnings.

    I suspect that it is in relation to custom post types (all themes that do not have these configured seem fine) but I am not fully there as to what is happening.

    I may be talking nonsense, but I hope that this input will help to pinpoint where the problem is and hence a fix.

    Best,

    Mark.

    Hi Enrico,

    I have the same issue, but I have recreated it on a clean install as follows:

    I did clean install of WP5.6.
    I then installed Elementor 3.0.16
    Followed by Yoast DP 4.0.2

    Nothing else.

    When I run this with 2021 theme all is well – no errors.

    I then installed and activated Rife Free theme (no framework data etc – just the theme files). Once this is activated I get the errors.

    Looking at the area where it is broken (class-post-list.php line 63), it seems that the query to get posts__not_in value is returning a null value in this function.

    I was looking a bit deeper, but as I noted that you are receiving other information about this issue, I thought I would at least pass this to you before continuing.

    I am not that familiar with this stuff, so I am not sure at this moment in time why the theme has an effect on how or why this function is called….

    Anyway, hope that helps,

    Mark.

    Thread Starter markc369

    (@markc369)

    Hi Bartek,

    There are a couple of things to consider…

    Firstly, this is only my workaround – it is not fully tested and I only made the change that worked when you select the “Cover the whole screen” option in the home page album. Note that the changes are within the apollo-framework-extensions plugin so any updates to this plugin will probably remove your updates to it – there was an update today that did exactly that ….

    Secondly, the plugin calls the minified version of the a13-slider.js, so you either have to change it to call the non-minified version or you have to make the changes and create a new minified version to replace the existing one – which is what I did.

    The details:

    1. To get the plugin to use the non-minified version (for testing) I added this line to the wp-config file:

    define( 'SCRIPT_DEBUG', true );

    Once testing was completed and I had a new minfied version, I removed/commented this.

    2. I edited the following file:

    wp-content\plugins\apollo13-framework-extensions\assets\js\a13-slider.js

    My previous entry above has the details of the fix, but also, when compiling the minified version, I got an error due to an empty if statement (around line 1170). I just commented this out.

                //load native video API
                //if(loadNativeVideoAPI === true){
                    //load mediaElement API
                    //loaded already
                //}

    3. I then minifed the updated file, replacing the original, and all works fine (I use Google Closure within Visual Studio Code).

    Alternatively…

    4. If you prefer to use the non-minified version, you can either leave the script_debug line in place (not very good), or you can edit the Assets.php file: :

    wp-content\plugins\apollo13-framework-extensions\features\assets.php

    Just change ‘js/a13-slider’ . $suffix . ‘.js’ to ‘js/a13-slider.js’

    Again, not really the best thing to do.

    Hope that helps.

    Mark.

    Thread Starter markc369

    (@markc369)

    Hi Air,

    Thanks for the reply.

    I had another look at this and was able to see that FireFox is returning an incorrect (and inconsistent) width for the slider container. I am guessing that this might be based on the time to load before it gets the width. On a fast server, it seems to work better than on a slow one… I have only tested the “fit_cover” option as this is the one I was using and the one that is broken for me.

    The way that I fixed (bodged) this was to change what is being used to generate the slider width in the a13-slider.js file.

    //  Resize each image
     elem.each(function(){
         var this_image = $(this),
         image_height  	= this_image.data('origHeight'),
         image_width  	= this_image.data('origWidth'),
         //space_width    	= $slides_list.width(),
         space_width    	= $window.width(),
         space_height   	= $slides_list.height(),
         image_ratio 	= (image_height/image_width).toFixed(4),
         space_ratio 	= (space_height/space_width).toFixed(4),
         resize_width	= 0,
         resize_height	= 0,

    I simply swapped out using $slides_list for $window. Watching the results, with this change in place the width was consistent every time and therefore the image was correctly sized and positioned each time.

    I could not see any downside of this nor a situation where the slider container would not be the same size as the window…but I might be wrong.

    Anyway, thanks for the input and this workaround seems to fix it for me!

    Regards,

    Mark.

    • This reply was modified 3 years, 10 months ago by markc369.
    Thread Starter markc369

    (@markc369)

    Hi Air,

    Thanks for the response.

    I did set up a live site to see if I could show you the issue, but it works perfectly on the live site – typical!

    https://alpujarrahabitat.com/

    I added the screenshot of the error just below the slider on the home page so you can see it, but you are probably not going to be able to recreate it.

    I normally develop using XAMPP on a few different virtual machines (with different versions of PHP etc). I created a brand new install with PHP 7.4.13 (same as the live site), and I still get the error – so I am guessing that it is something to do with the default XAMPP dev setup.

    As this is not showing on the live site, and is only showing on FF on the development environment, I think it best to just mark it as resolved.

    Best wishes,

    Mark

    Hi Air,

    Thanks for providing the fix. I had put a trace on the image size and could see that it was being returned as zero outside of the viewport but only on Firefox.

    I had even tested with using a fixed height set in that same function which fixed it but would mean that I would have had to have all images set to that size! (not a great fix).

    I would not have known to set ‘loading = false’.

    Thanks,

    Mark.

    Hi there,

    I have come across the same issue (on a pretty much clean install). I have not done a lot of investigation (as in I have not dug into the code), but I have found a few things:

    What I see happening:

    The blog entries do not space correctly down the page if there is more than one page of entries (pagination) or if lazy loading kicks in as you scroll down the page (using lazy loading).

    Where is this happening:
    The only browser I see the problem is Firefox and Firefox Developer. It does not occur in Edge, Chrome or Safari (MAC).

    What I have tried:
    I have tested this in a clean install with no additional plugins installed. I have turned off lazy loading for Albums and anywhere else I can find it being used. I have tried all the “Post Look” styles, but they all suffer the same issue. Same with Masonry v Each row from new line.

    Checking the Console on Firefox I do see this message – which may or may not help…

    “This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://developer.mozilla.org/docs/Mozilla/Performance/ScrollLinkedEffects for further details and to join the discussion on related tools and features!”

    Hope this may help, but if you need further information, then I am more than happy to provide…

    Many thanks,
    Mark

Viewing 12 replies - 1 through 12 (of 12 total)