Forum Replies Created

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

    (@pm1932)

    Same error while updating on WPEngine

    php 8.2

    wp: 6.4.3

    I placed a ticket in and WPE and got a response

    Hi pm1932,

    I’ve just heard back from our engineering team and they confirmed that this does appear to be an issue on our end as we also had another report of a similar issue previously. Thankfully they already have a fix that’s being worked on that should hopefully be going out soon so we can update you when that’s been done and have you test on your end.

    Regards,

    …., Technical Support Specialist

    WP Engine, Inc.

    I’m pretty confident this is a WPE issue because it doesn’t seem to affect all sites in the same manner. It only seems to be affecting our clients on the dedicated plans. All clients on the cheaper shared plans do not seem to have this same issue even though they are running the same version of wordfence 7.9.2. All clients on the more expensive dedicated plans are experiencing this issue.

    I’m not experiencing any issues locally with the same codebase that I have on WPE. and I’m getting the error on WPE dedicated plans without other plugins (wordfence is the only plugin activated) and using a default WP theme.

    I don’t know if anyone else is having the same issue but WPE support seems to be able to run wpcli just fine from their end. so I’m not sure what’s up with that. For the record if anyone is thinking this might just be wordfence’s FW, I have my IP in the allow list and even with the firewall disabled I get the same behavior (commands just hang until I close the terminal window).

    Anyway, I hope people keep contacting WPE until this is resolved. the other thing I’d mention is using the “–skip-plugins=wordfence” flag will allow you to work around this issue. I’d recommend creating a wp-cli.yml in your root and paste:

    skip-plugins:
    	- wordfence

    this should allow you to run wpcli without having to type the flag out everytime.

    Thread Starter pm1932

    (@pm1932)

    I ended up solving this by simply deactivating the plugin and activating it again.

    Thread Starter pm1932

    (@pm1932)

    so I can access my 2FA settings at /wp-admin/network/admin.php?page=WFLS but

    /wp-admin/admin.php?page=Wordfence
    and /wp-admin/network/admin.php?page=Wordfence give me:

    “Sorry, you are not allowed to access this page.”

    I am a super admin so I’m not sure where to go from here.

    EDIT: I also checked with another network super admin and they are seeing the same

    • This reply was modified 3 years, 4 months ago by pm1932.
    • This reply was modified 3 years, 4 months ago by pm1932.
    Thread Starter pm1932

    (@pm1932)

    Hi Milos,
    Thanks for your reply and video. Ultimately yes, the layout you have at the end is what I’d like to achieve but I’d like to do it without nesting blocks. Some of our clients are not very technical so we need to make things as easy as possible. Which is why we love coblocks and why we also try to avoid nesting blocks as much as possible.

    At the :08 second mark in your video, instead of selecting “100”, I’d like to select “50/50”.

    once 50/50 is selected you can fill in the content in your columns and add a background color and everything works fine. but if you click on the wordpress block alignment to make the block go full width the columns also go full width. Now, I understand this is probably smart for coblocks because there are probably some times where you might want columns that go full width.

    …but if the background images or color was attached to wp-block-coblocks-row instead of wp-block-coblocks-row__inner I could use wp-block-coblocks-row__inner to assign a max-width and center that div (centering my columns on the page). or probably more backwards compatible if you added an additional wrapper inside wp-block-coblocks-row__inner that I could set a mx-width and center to I could get around the block nesting.

    patterns are making this less of an issue. but I thought I would ask just in case I was missing something.

    Thanks again

    Thread Starter pm1932

    (@pm1932)

    I went back and forth with support on this. tunred out to be a bug. you can fix, by unchecking roles in 2FA settings. save. then recheck roles. save. it was kinda buggy so some times it worked other times I had to only uncheck one. save. recheck. save. I would recommend just checking and unchecking, saving every time until you get it.

    Thread Starter pm1932

    (@pm1932)

    In case anyone else was looking, here’s what I ended up with

    function nrd_before_any_command() {
        if( 'search-replace' == WP_CLI::get_runner()->arguments[0] ) {
            WP_CLI::confirm( "testing..." );
        }
    }
    
    WP_CLI::add_hook( 'before_run_command', 'nrd_before_any_command' );
    Thread Starter pm1932

    (@pm1932)

    Thanks for your solution @bcworkz. The only issue I can see is you’d have to manage your host file pretty tightly. With all the clients/sites we have I can see me forgetting what’s in my local hosts file and getting confused if I’m looking at the live site or the local site. It’s a possibility though and I will think about it. Thanks!

    Anyone else have a workflow they’d like to share?

    Thread Starter pm1932

    (@pm1932)

    thank you @fritex and @vmarko

    @vmarko I upgraded to the pro version and it’s still not working. Basically no change. the cookie groups continue to work perfectly on the homepage and archives as they did with the community version. but single pages/post still save a version based on the cookie but it’s a duplicate of the already cached file not a new file with the correct menu. Pretty sure it’s just loading the cached page and then making a copy of that instead of generating and saving a new page.

    Forum: Plugins
    In reply to: [Schema] Error

    To me this seems like a bug. I get this error after I update a page and then go to view that page. If I refresh again I don’t get the error.

    The problem seems to be that $pttimestamp_old can get set to an empty string which still returns true at the isset if statement:

    
    //
    // /wp-content/plugins/schema/includes/json/schema-output.php on line 43
    //
    if ( isset($pttimestamp_old) ) {
    	$time_diff = $pttimestamp - $pttimestamp_old;
    	if ( $time_diff <= DAY_IN_SECONDS ) {
    		$json = get_post_meta( $post->ID, '_schema_json', true );
    	} else {
    		delete_post_meta( $post->ID, '_schema_json' );
    		$json = array();
    	}
    }
    

    changing isset to !empty should make the error go away but hopefully the devs will come up with a fix in a future release.

    Thread Starter pm1932

    (@pm1932)

    oops, looks like this has already been updated in a later version.

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