robwatsondz

I attempted to do the following:

// dequeue OpenStreet layers from Directorist plugin as we're not using maps
add_action( 'init', function () {
    wp_dequeue_script( 'directorist-openstreet-layers' );
} );

but apparently that’s not the proper handle for dequeueing this script.

Thanks. I hesitate to alter the plugin code in case I break something. Also, if I alter the plugin code now, when the next update happens I’ll lose the changes I made. Unless there’s a reliable way you can think of to dequeue it via the functions.php of my custom theme, I’ll just wait until you have implemented better optimization including this issue.

@m4hd1bd Also, please note that the environment I gave access to in the ticket is read-only in terms of adding plugins or code. If there’s anything that needs to be added, let me know and I’ll add it.

@m4hd1bd I’ve submitted a ticket via the directorist.com/contact page.

Yes, that may be the case. I wasn’t able to find the same error message in the php-error.log file itself. The error reported above is from a hosting console that surfaces errors for me to review. Thanks.

One thing I also just noticed is that if I switch to List view in Media Library, searches are able to complete in 30-40 seconds even with the normal plugins and theme turned on. So, apparently there’s some issue with searching while Grid view is enabled. Does that shed any light on why this is happening and how to improve performance?

Thanks Dion. One thing I’ve had success with in terms of actual posts and pages is the Index WP MySQL For Speed plugin, which did the index optimizations and improved the query times for posts and pages, including wp_postmeta. I guess it just can’t do enough to optimize indexes for so many media library items?

I’m using the latest version, which is Version 7.2.0 on WordPress 5.9.3.

Thanks for retesting and for the link. I’ve now reported it as an additional comment on that same bug. https://github.com/WordPress/gutenberg/issues/37982#issuecomment-1103140793

I just now attempted it with a fresh WP install on my local machine (MacBook M1 2021 running Chrome 100…see https://www.whatsmybrowser.org/b/G105U for details). Instead of copying and pasting text from somewhere else, I did the following ONLY typing, not pasting:

• Add new post
• Type (not paste) “test” as the title
• Type (not paste) “test” as the first paragraph
• Type (not paste) “test” as the second paragraph
• Save the post
• Exit the post
• Edit the post
• Click in the title to know whether it’s editable (it is)
• Select the first paragraph by clicking and dragging over its text
• Continue dragging the mouse selection into the next paragraph. Both paragraphs will now have a colored border around them.
• Click the title to know whether it’s editable (it is not editable now)

Unless there’s something inherently wrong with my browser, OS, mouse, or keyboard, I can’t see how it’s the content or the WP setup. It’s a completely fresh WP install and all content is typed, not pasted.

I did ensure to attempt the above with the plugins all turned off and the theme switched to Twenty Twenty. I just tried it again, with ALL plugins disabled and the theme set to the theme set to Twenty Twenty and the same problem is occurring.

UPDATE: This problem seems to occur when the user clicks and drags to select more than one paragraph block. If you click and drag to select the text in a single block (without crossing over the “boundary” of the block and beginning to select the next one) and then delete the selected text, the title can still be edited. Likewise, if you delete one paragraph block at a time using the block’s control, the problem doesn’t happen. It is only when you click and drag across 2 or more paragraph blocks that the title becomes uneditable until you save, exit, and re-enter the editor.

Even with dynamic mode enabled, the ads don’t rotate in any mobile browser. Not Safari, Chrome, Firefox, or Brave. Is there something else I can try?

We are using WordPress 5.8.3, which is greater than the required 4.6. When the site launches it will be on 5.9.

We are using PHP 7.3.33, which is greater than the required PHP 7.2.

We are using MySQL 10.0.23-MariaDB-log, which is greater than the required MySQL 5.6.

Our PHP memory limit is 256M, which is the preferred amount.

Nevertheless, the problem still happens and seems to be centered on a bad SQL query that maybe wasn’t tested on all versions of MySQL.

I re-ran the install and demo setup from scratch and this time I kept track of all the error logs at each step of the way. See the gists below for the errors. There are tables that just aren’t getting created in Pantheon’s database (InnoDB) upon activation of the plugin. That’s probably the main issue, but I don’t think the root cause is timeout related as the tables that did get created during activation didn’t take long to create. This is where I’m stuck, until all the tables can be fully created, with or without the demo being imported. No new listings can be created without the missing tables.

uListing php-error.log creating user tables upon activation on Pantheon
https://gist.github.com/crobertwatson/68ddf9558cec34731e52dd2cba7837d2

uListing php-error.log after demo creation and clicking on Listings
https://gist.github.com/crobertwatson/b67276591889aab8a485873ae2679b9e

uListing php-fpm-error.log after demo creation and clicking on Listings
https://gist.github.com/crobertwatson/cb3fb2d82781f0a0d99c2c9930d8e2a9

uListing php-slow.log after demo import and clicking on Listings
https://gist.github.com/crobertwatson/d929461adc5075497c6cd66d9694b55b