We're merging with GenerateBlocks! Learn more here.

Support Forum

Please login to receive premium support.

Support for the free plugin can be found here.

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 20 total)
  • Author
  • in reply to: Is Specific WPSP CSS Applied Sitewide? #11606

    Where possible, we load CSS specific to each list directly above the list in the HTML. This makes it so less CSS is added site-wide.

    This is what I was asking, to avoid the case where code from a completely unused yet still published WPSP was adding sitewide CSS.

    Simple CSS is an excellent plugin and I use it. I hear the inventor is a nice guy!

    Thank you very much for your help Tom πŸ™‚

    in reply to: Is Specific WPSP CSS Applied Sitewide? #11594

    Hi Tom,

    As a user of GP Premium, I can see just how much effort you put into performance – so I had no doubt you were following best performance practices.

    That said I didn’t realize there wasn’t even an *option* for this kind of functionality. No wonder so many plugins have this issue.

    Just one more question to add to this then: does that mean that I should delete and/or draft any of the WPSP that I’m no longer using?

    Otherwise wouldn’t that mean that their specific CSS associated with them, e.g.:

    e.g. there will be this code:

    #wpsp-123 h2 {

    Would be on all of my wordpress pages – even though the shortcode isn’t used? Since you can’t see if the WPSP is being used, I would presume that you publish the CSS based on its published/draft status?

    I realize this is a tiny amount of CSS, but if it’s WPSP that I’m no longer using then there is no point keeping them around if it’s adding even a tiny amount of CSS.

    Please let me know whether I can draft these posts to remove the CSS associated with them, or whether I need to delete the specific WPSP altogether.

    Thank you very much for your help Tom!

    in reply to: Is Specific WPSP CSS Applied Sitewide? #11510

    Sorry for my poorly worded question Tom, that’s not quite what I meant.

    Rather, is there some WPSP CSS code baked into the plugin that is specific to each WPSP, but is being shown site-wide?

    e.g. there will be this code:

    #wpsp-123 h2 {

    Shown on all page. This CSS code is specific to WPSP with ID 123, but is still being shown on the page even if this particular WPSP is not present on a particular page (but another WPSP is).

    Coming at it from a performance standpoint πŸ™‚

    in reply to: Heavy MySQL Usage via admin-ajax.php #11442

    Sadly not Tom. This is what is showing up: https://imgur.com/DuK1tUO. The code is activated via code snippets, and is simply:

    add_filter( 'wpsp_pro_beta_tester', '__return_true' );

    in reply to: Heavy MySQL Usage via admin-ajax.php #11397

    Hi Tom.

    Please excuse the (extreme) tardiness of my reply.

    I had added this code via the method you recommended: https://imgur.com/369d2wX + https://imgur.com/LIymqKA

    I presumed that was all I needed to do. But reading the guide again, I realized that this was just to *show* the plugin updates. When I check my plugin dashboard though, the version is still on 0.5: https://imgur.com/DuK1tUO

    Am I doing something wrong? If this doesn’t work I can always try the manual upload method – but I wanted to try this method first, since I was (am) hesitant to delete WPSP and reupload.

    Thank you very much for your support Tom.

    in reply to: Remove WPSP For Non Admin Uses #10364

    Hey Torbjorn,

    I noticed that in the Capability Manager Enhanced plugin now has an option to enable Permissions for WPSP. It’s in the right hand pane of the plugin when you navigate to Users -> Capabilities, as seen here: https://imgur.com/a/5pDoXqc (“Post Lists”).

    This enabled you to control WPSPs permissions for your Authors/Editors/etc. just like you would a WordPress page/post – very handy! Pretty much all “Out of the box” now πŸ™‚

    in reply to: Heavy MySQL Usage via admin-ajax.php #9996

    That’s awesome, thank you Tom.

    I downloaded the plugin, but I’m unsure how to update the plugin without losing all my existing WPSPs.

    If I delete v0.5 and upload the latest version – will I lose my existing WPSPs? I’m not sure where this data is stored.

    Apologies for my ignorance.

    in reply to: Heavy MySQL Usage via admin-ajax.php #9743

    Hi Tom,

    Thank you for the code fix. Response from WPX (paraphrasing):

    “!is_admin() won’t work because it returns ‘true’ on ajax requests but !is_user_logged_in() seems to work for front-end requests but I don’t know what is best, so the developer should decide.

    The query will run on every back-end request so there will be less usage, hopefully, the plugin will be updated with a similar fix as the developer recommends.

    I’m not sure that users will need this query to run on every page(with ‘admin-ajax.php’) when they are logged in.

    Thank you to the developer because he didn’t ignore the case, we have had similar cases from other plugins that were just ignored without any performance fixes!”

    So it seems like a significant improvement at the very least! Thank you very much for your assistance on this issue Tom. I’m sure you have loads of priorities, but do you plan on implementing this or a similar fix as an update to the plugin?

    Thank you kind sir.

    in reply to: Heavy MySQL Usage via admin-ajax.php #9683

    Hi Tom,

    My hosting company (WPX Hosting – I need to shout them out because they have been gems in holding my hand through this) has just made a very useful discovery. I’ll quote:

    *Begin quote*
    I have just tested that but the query is directly called from the action ‘admin_init’ with function ‘wpsp_pro_update_read_more_values’ in WP Show Posts Pro – ./wp-show-posts-pro/inc/admin.php – https://imgur.com/3Gpa3pw which is somehow bound to every ‘admin-ajax.php’ call.

    Note: admin_init – “It runs on admin-ajax.php and admin-post.php as well.” – Source: https://codex.wordpress.org/Plugin_API/Action_Reference/admin_init

    Here is what I tested on the staging site:

    1. I disabled/enabled each plugin and checked on which request was the query called.
    -The query was called on every ‘admin-ajax.php’ request when I was logged in in the ‘wp-admin’ area of the site even if all plugins were disabled except for ‘WP Show Posts/Pro’.

    2. When there aren’t any ‘admin-ajax.php’ calls then there isn’t an issue because this specific function is not being executed on the front-end of the site.
    -If Thrive Leads is disabled then there aren’t any ‘admin-ajax.php’ calls and the queries are not being called on the front-end for non-logged in users.
    -This can happen with other plugins that use the ‘admin-ajax.php’ for handling actions, as proof, I have tested it with the plugin ‘Post Views Counter’ that runs an ‘admin-ajax.php’ call on every post/page visit and managed to see the query running on each one when Thrive Leads was disabled.

    If ‘WP Show Posts’ doesn’t make the query via the ‘admin_init’ on each ‘admin-ajax.php’ call then those queries won’t be called on the front and backend of the site.

    I hope this helps and the plugin developer might be able to provide a fix that can avoid the query call on each ‘admin-ajax.php’ request.

    *End quote*

    Don’t really have much else to add to this – I hope that helps Tom πŸ™‚

    in reply to: Heavy MySQL Usage via admin-ajax.php #9639

    Thanks for the information and link Tom. Response from my hosting company:

    “This was one of the first things that I have tried that but didn’t see the query in the Query Monitor on any of the pages of the staging site.

    If it’s a background task then it might be a WordPress cronjob but all cronjobs that are currently active on the site are with a minimum recurrence of 1 hour.

    I doubt that the query will be displayed because the ‘admin-ajax.php’ is being called with a delay on the front-end due to the loading priority of the files/scripts.”

    So if your plugin only makes calls on the dashboard, then can we rule out that its WP Show Posts directly? It seems like we’re leaning towards the possibility that it’s another plugin that’s for whatever reason iterating through the posts in WP Show Posts?

    in reply to: Heavy MySQL Usage via admin-ajax.php #9593

    Apologies for the late reply Tom, I was trying to sort out this issue (we fixed the caching on Cloudflare’s side, but the queries are still present in bulk when I’m forced to purge the cache). I couldn’t find the query using the query monitor plugin.

    I spoke to my hosting about it, and they said:

    “The queries are most likely not shown in the query monitor because they are somehow connected to the ‘admin-ajax.php’.

    Unfortunately, we do not have the debug tools in order to identify the direct caller.”

    We tried disabling other plugins but the queries were still present. Do you have any other ideas as to what this might be?

    in reply to: Heavy MySQL Usage via admin-ajax.php #9491

    To clarify the above:

    *When I drafted one of the WPSP lists posts, the same query executed but without the post ID (i.e. the WPSP list) that I had drafted

    in reply to: Heavy MySQL Usage via admin-ajax.php #9490

    That’s correct Tom – all of them are from WPSP (yes I have that many – I love your work ;)). I’m not sure what you mean by “happening” on the front end – but the query is being executed every time someone visits the site. Note that all pages have at least 1 WPSP on the page, since I use one of them as a shortcode executing in the sidebar.

    When I drafted one of the posts, the same query executed but without the post that I had drafted (i.e. the drafted post disappeared from the query).

    To further troubleshoot this issue, I have added a “post” to the site (there are currently none, only pages). I will see if this “post” appears in the query, or if the post IDs are still exclusive to WP Show Posts. I will report back with this information asap.

    in reply to: Heavy MySQL Usage via admin-ajax.php #9460

    Hmm, that’s odd.

    To clarify my previous comment, all of the Post IDs mentioned in the query are posts from WP Show Posts. I don’t actually have any “Posts” (literally none) on the site – it’s all pages.

    There are only two types of lists I’ve created (using wp show posts):

    1. A list for every category (references the wordpress category). Each one of these wp show post shortcodes appears on 1 page only, often with other similar wordpress category wp show post lists (e.g. https://imgur.com/bcmNE95)
    2. A list that includes every page on the site (https://imgur.com/S7l9S4w). This appears on basically every page on the site. Although this is suspect given its prominence across the site, note that this references pages – not posts. And all of the IDs listed in the query above are posts (from wp show posts)

    Really am stumped on this one. Is there any way to reverse engineer where this query is coming from? As mentioned, it disappears when I disable the plugin.

    Thank you for your help Tom.

    in reply to: Heavy MySQL Usage via admin-ajax.php #9443

    Hi Tom,

    After disabling the plugin the queries seemed to disappear, so we’re fairly sure these queries are coming from wpshowposts.

    Any ideas on how we can reduce this mySQL usage? I’m also a bit confused as to what this query is doing, since it seems to be referencing all of the POST IDs exclusive to WP Show Posts.

Viewing 15 posts - 1 through 15 (of 20 total)