Support » Plugin: Display Widgets » Version 2.6 very, very slow!

  • Resolved KTS915


    I have been using this plugin for a long time. It’s one of the first I install on any site. Thank you!

    I have never really understood the calls for an update. Everything was working fine. If it’s not broken, don’t fix it! And, sadly, I see that, using Query Monitor as my gauge, version 2.6 now causes a page to take between 0.15 and 0.5 seconds longer to load than before. (It also “feels” much longer to the user.)

    In case it helps you to know this, I am running this currently on a localhost development site using PHP 7.1.

    I don’t know whether this slowness suggests a bug or error, or whether the new code works as intended but is just very slow. I am reporting it here so that you can take a look.

    Query Monitor is not reporting any errors, though, so I fear that this slowness is simply the product of the new code.

    For the moment, therefore, I am not going to install the update on any more than the one test site on which I have it now. If it turns out that updates from now on are always going to cause my sites to be so slower, then, regrettably, I’ll have to revert to the previous version and stop using your updates.

Viewing 11 replies - 1 through 11 (of 11 total)
  • Hi,

    It is due to the geolocation code conflicting with another plugin. We are updating the code today, so if you simply update later and on the setting page click the “Turn Geo Off” it will be like normal :).

    Sorry for any inconvenience. Simply check the new update today.



    Are you joking?

    What on earth is geolocation code doing in a plugin for displaying widgets?

    If you wanted to mess about with the plugin like that, you should have forked it and created a new one instead.

    Honestly, I thought you were developers who knew better. Apparently not.

    You can upgrade to a forked version of the plugin:

    Works the same as the old 2.05 version with bug fixes and new widget logic features and no geolocation code.


    @seo Dave, actually, I have been testing your plugin for about two weeks on a test site. Sorry, but I absolutely hate the interface you’ve introduced.

    If you revert to the original interface, then I might consider using your plugin on a production site. But, otherwise, I see such fiddling and mention of “SEO,” which is irrelevant to me, and wonder what else are you going to fiddle with.

    Version 2.05 works fine for me. I need a compelling case to move away from it. So far I haven’t seen one — from anyone!


    Thanks for the feedback on the interface, no need to be sorry we all have our own opinions of how something should/shouldn’t be. Is it the having to click the +/- ‘headings’ to open the checkbox areas you don’t like?

    Since I added all the new widget logic options and options for bbPress/BuddyPress/WPML plugins, if I kept the original interface (all the forms open at the start) it could be really cluttered with long lists of checkboxes!

    For the record I got the idea from another Display Widgets user from this thread

    I plan to keep the current interface, but it’s a really simple change that created the new interface. In the file


    Change lines 979-981 to:

    .dwsp_collapse {
    //	display: none;

    All the checkboxes will now be open. Obviously you’d have to make this manual change after each update.

    If you look through the changelog at you can see if any of the bugs have an impact on how you use the plugin.

    Changelog changes related to v2.05

    Bug Fix: The WPML Language plugin issue related to transients and the register_globals() function being called three times – Issue left over from the original Display Widgets 2.05 plugin code.
    Bug Fix: The WPML Language plugin issue related to when the “WPML” > “Languages” : “Make themes work multilingual” – “Adjust IDs for multilingual functionality” option is ticked resulting in duplicate Categories listed under “Categories +/-” – Required two more WPML filers removing when the “get_categories()” function was called.
    Bug Fix: The Display Widgets SEO Plus transient (Static Pages, Categories cache etc…) not deleting when a Post/Static Page was saved – Original Display Widgets v2.05 uses the wrong WordPress hook.
    Bug Fix: The Display Widgets SEO Plus transient (Static Pages, Categories cache etc…) not deleting when a Taxonomy (Category for example) was saved or deleted – Missing hooks in original Display Widgets Plugin v2.05.

    Rebuilt the code behind the Display Widgets SEO Plus transient cache: the new code is more efficient and works correctly now.
    New Feature: Added support for the BuddyPress plugin (see below).
    New Feature: Is ALL BuddyPress Pages – is_buddypress()
    New Feature: Is BuddyPress Members Directory – bp_is_members_directory()
    New Feature: Is BuddyPress User Pages – bp_is_user()
    New Feature: Is BuddyPress Activity Streams Directory – bp_is_activity_directory()
    New Feature: Is BuddyPress Activity Streams Item – bp_is_single_activity()
    New Feature: Is BuddyPress Groups Directory – bp_is_groups_directory()
    New Feature: Is BuddyPress Group – bp_is_group()
    New Feature: Is BuddyPress Group Forum – bp_is_current_action( ‘forum’ )
    New Feature: Is BuddyPress Group Forum Topic – bp_is_group_forum_topic()
    New Feature: Is BuddyPress Registration Page – bp_is_register_page()
    New Feature: Added support for the bbPress plugin (see below).
    New Feature: Is ALL bbPress Pages – is_bbpress()
    New Feature: Is bbPress User Pages – bbp_is_single_user()
    New Feature: Is bbPress Forum Archive – bbp_is_forum_archive()
    New Feature: Is bbPress Category Forum – bbp_is_forum_category()
    New Feature: Is bbPress Forum – bbp_is_single_forum()
    New Feature: Is bbPress Forum Topic – bbp_is_single_topic()
    New Feature: Is bbPress Topic Tag – bbp_is_topic_tag()

    First release: Built from the Display Widgets Plugin v2.05 with the addition of lots of new conditionals (see below list of New Features) and an improvement how widgets are hidden/shown when the WPML languages plugin is active.
    New Feature: Is Dated Archive – is_date()
    New Feature: Is Author Archive – is_author()
    New Feature: Is Tag Archive – is_tag()
    New Feature: Is WordPress Post – is_single()
    New Feature: Is Static Page – is_page()
    New Feature: Is Attachment Page – is_attachment()
    New Feature: Is Custom Post Type Archive – is_post_type_archive()
    New Feature: Is Specific Custom Post Type – via get_post_type()
    New Feature: Is Paged Archive/Paged Comments – via is_paged()
    New Feature: Is Specific Categories
    New Feature: Is WordPress Posts Within Specific Categories
    New Feature: Is Specific WPML Languages Plus Other Widget Logic Options

    Other than adding new conditional logic for plugins like Woocommerce the plugin is pretty much complete: it works, think I have all the bugs ironed out, so no need to mess with anything.

    The SEO information is explaining how I use it to build silo SEO link structures, has no impact on how the code works: it’s a perfect plugin for managing how internal links are managed through a site, for example I tend to have the categories widget to NOT load on Posts/Pages as the cat links anchor text tend to ‘water down’ the anchor text benefit of related links to Posts/Pages.

    As I’ve mentioned previously the old v2.05 code (you can get it here is a stable release and works for many users (I wouldn’t use the new v2.6 code, it’s got the geolocation bloated code and has new bugs). If the bugs listed above aren’t causing problems and you have no need for more widget logic conditions (you don’t use bbPress, BuddyPress or the WPML plugin) there’s no need to change from v2.05 (it’s a good plugin).

    BTW I’d be interested to hear your feedback on speed? I’m obsessed with performance for SEO reasons (Google cares about speed) and would hope the new code runs more efficiently vs the old (worst case scenario should be the new Display Widgets SEO Plus Plugin has identical performance to the v2.05 code).


    Dave, thanks for being both responsive and transparent. I appreciate it.

    When comparing DW 2.05 with the current version of your plugin, I don’t see any difference in speed on the website (either in “feel” or as measured by Query Monitor).

    However, I do notice a huge lag in terms of my being able to set anything up using your plugin. I think the commenter from whom you got the idea of a different interface is 100% wrong. Because your plugin forces me into several additional steps compared to the original Display Widgets.

    First, I have to think of how to categorize the place where I want a widget to appear or be hidden. I can’t just scroll down and see what I want. I have to think, is it a post or a custom post type, or whatever? Because otherwise I’ll be opening the wrong box, and then wasting time looking for something that isn’t there.

    Second, if I need to choose both a post and post type, I have to close one box and open up another! How on earth is that an improvement? Before, I could just scroll and tick boxes, but your plugin insists on extra steps. And if I want to do categories and other things too, that means doing all that closing box, opening box, and scrolling down all over again. No thanks!

    Third, what’s up with posts anyway? You put posts at the end, but that’s just for IDs. So you now force me to guess where to find posts. Hint for anyone else reading this: they are under “Content Types,” though I’d have thought that covers everything anyway. So I have to guess what your headings mean in order to use them.

    So, unlike your responsiveness here, it’s a bit of a UI nightmare. I wouldn’t use it unless I absolutely have to. And I don’t have to. I don’t use WPML, and I wouldn’t touch BuddyPress or bbPress with a long stick.

    So I have just renumbered Display Widgets version 2.05 as version 102.05 to stop any update nags and will carry on using it as before.

    I think I understand your main complaint.

    The original plugin in terms of widget logic options is quite limited, you couldn’t set a lot of basic widget logic conditions like

    Is Dated Archive – is_date()
    Is Author Archive – is_author()
    Is Tag Archive – is_tag()
    Is Static Page – is_page()
    Is Attachment Page – is_attachment()
    Plus all the BuddyPress/bbPress/WPML plugins (if used) widget logic options.

    So using the original plugin (v2.05) was much simpler (handful of basic options) and could easily all be loaded at the same time without it scrolling down multiple pages other than if you had a site with lots of Static Pages and/or Categories (I own huge 50K+ Post sites with hundreds of categories).

    With my upgraded plugin I’ve categorized the different types of widget logic (there’s more menus of checkboxes) and have set the menus by default to be minimized resulting in the user having to click the +/- headings. Note: you don’t have to close a +/- heading to open another +/- heading, you can have them all open at the same time.

    I’d say to match the old plugin output you would click these headings-

    Categories +/-
    Content Types +/-
    Static Pages +/-
    WordPress Posts +/-

    To get a similar output (starting point) you have 4 additional clicks assuming you wanted to have access to all the options at the same time and that’s slowing your work flow. I see the problem.

    Personally I find the new layout easier to use/manage. If you have a site even with a modest number of Static Pages (50 say) and decent number of categories (30 says), with the old plugin you have to scroll up and down the list for quite some time and/or use the +/- links (which are much harder to locate, requires scrolling) to hide a section to scroll less.

    It really depends upon your site layout, with a small number of Static Pages/Categories the old interface requires less clicks, but for larger sites the new interface is easier and faster to use.

    The “WordPress Posts +/-” section where you add Post IDs is at the bottom because it’s the least likely to be used by your average WordPress user. That option requires manually editing a Post, find the Post ID, copy/paste the ID into the form. Having it at the bottom means it’s out the way, but also easy to find. Hmm, good point on the label for that heading, might be better as “Specific Posts by ID +/-” to indicate it’s not a way to select all Posts which as you say is under “Content Types +/-“.

    Thanks for the useful feedback, I’ll have a think if I can design a simple single click option to open/close all the +/- menus.


    @seo-dave, I understand that you want to drive traffic to your plugin by bashing mine, but let’s try to work together instead of pointing fingers and blaming others, can we? I decided to take over this plugin simply because I used for a while, and seeing that the original developer was not updating it anymore made me think about the potential that this feature could have, and how it could be improved. I did it with no short term plan to make any money, it’s basically just the same passion that drives thousands of developers around the world to contribute to the open source community. So, with this in mind, can we collaborate and work together on improving the plugin instead of doing what you’re doing? Thank you!


    please note that version 2.6.1 is not bloated anymore. Monetizing a plugin is always tricky, thank you for suggesting this idea. I believe people will like this feature to be able to hide/show certain widgets by Country. I am planning to add more features and eventually create hide/show “profiles” in a separate admin screen. This way you don’t have to set all the checkbox for EVERY SINGLE widget you add to your sidebars, but you can simply select a profile from a dropdown. Plus, what about hiding/showing a widget based not just on users being logged in, but also based on capabilitites associated to a given user, and so forth? As you can see, I have many ideas, and I hope the community will stick with me.



    Thanks very much for the insult!

    You paid money for the Display Widgets plugin from the original developer: few people would buy a plugin without a long term plan to recuperate their investment.

    Your 2.6 update (which added new bugs) broke multiple WordPress Plugin Repository rules (appeared you were tracking users IP addresses without their permission**: that’s valuable user data and there was no way to turn it off) resulting in WordPress deleting the Display Widgets plugin.

    You’ve been dark (not answering support requests, no posts here at all) for about a week, no one knew what would happen to this plugin and I was the only person around offering any support (would it have been better to be quiet?). IF my intention was to drive traffic to the much better Display Widgets SEO Plus Plugin I’d have actually trashed the 2.6 code a heck of a lot more than what I’ve posted.

    Users didn’t know what to do, through various support threads I recommended either downgrading to the old 2.05 version or upgrade to my version (the easier and without knowing if this plugin would be reinstated the best solution) : in some of my responses I suggested both at the same time including linking to the 2.05 zip file giving users a choice.

    ** Had a quick look at the code and the new 2.6.1 version appears to still track users IP addresses, but the site owner has to activate the feature under the plugins admin page. If the calls to (within the code of the geolocation.php file) are doing what I think they are doing you can track users by IP address gathering valuable data you can use/sell.

    I’ll ask outright, are you tracking and/or storing the data?


    Thanks very much for the insult!

    I’m sorry, how is an offer to collaborate an insult? I am not used to feed trolls, so I will not reply to your attacks anymore, as they are going to clog this forum with silly stuff, instead of leaving room for ACTUAL support requests. Thanks anyway and good luck with your plugin.



    You wrote this half a dozen times:

    @seo-dave, I understand that you want to drive traffic to your plugin by bashing mine, but let’s try to work together instead of pointing fingers and blaming others, can we?

    You’ve accused me of trying to drive traffic to my plugin, that’s an insult!

    Now you are calling me a troll, so thanks again for another insult!

    I was in the process of writing a detailed response as to why the geolocation feature could get a site pennalzed by Google (trying to help you out), but I won’t bother now. I’ll wait for the inevitable complaints when Display Widgets users see their SERPs drop due to hidden content penalties.

    I note you didn’t respond to “I’ll ask outright, are you tracking and/or storing the data?”

    Are you tracking and/or storing the data?

    If not, say so, if you are that opens another can of worms related to EU laws etc…

    You can’t track users data without their expressed permission, this is not a simple case of getting the site owner to click a link to active the geolocation code (that gets you over the WordPress Plugin Repository requirement), you need the permission from those who’s data you are tracking and storing (selling?) (even collecting and not storing is an issue).

    If you are doing what I think you are doing I believe your plugin users would have to add a notification (similar to this added for advertising via AdSense etc…) their users data is being tracked and stored at You haven’t added this to the plugin, so Display Widget users who activate this feature could be breaking EU and other country laws.


Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Version 2.6 very, very slow!’ is closed to new replies.