Hey daggerhart, sorry to trouble you with the same issue again but…
I am running WP 3.51 and just installed Query Wrangler Version 1.5rc8. I was happy because it looks very much like a lighter version of Drupal Views that I’m used to. Unfortunately if I try and click any of those links, I get nothing. I cannot even change the default “5” posts to “1”.
So I don’t think we can mark this issue as resolved yet.
Hi Mcflims,
I just updated my test WP to 3.5.1, and I didn’t have any issue with QW’s interface. If you have firebug or are using chrome, could you tell me if you have any console errors on a query edit page?
It may also be related to another plugin, so if you have any js heavy or caching plugins installed, could you provide me with a list?
Thanks
Hi daggerhart, thanks for the quick reply. You can skip to the end and figure out where the conflict is. But I will leave this info in as well…
If I reload the Query Wrangler page with the View on it, I get an Ajax error from wp-admin/wp-ajax.php
200 OK
839ms
load-s…r=3.5.1 (line 2)
ReferenceError: wpa2a is not defined
[Break On This Error]
wpa2a.script_load();
But clicking any links I get nothing in FF and Chrome.
Chrome’s console tells me:
Uncaught ReferenceError: wpa2a is not defined
and it looks like I am using jQuery v1.8.3
Module wise I deactivated AJAX Thumbnail Rebuild and WP Google Fonts because they looked like they might be involved. But that didn’t help.
So then I started disabling all modules and got it to work! So then I turned them back on until I narrowed down the culprit:
Share Buttons by Lockerz / AddToAny
Version 1.0.3 | By micropat
Disabling this module solved my issue.
Thank you! I look forward to a Views-like experience.
PS… I am more of a “Drupal guy” would you say there tends to be more of these module conflicts in WordPress? I’m exploring the pros and cons. I definitely see WP has a better back end for site editors. I think the out-of-the-box publishing experience is much better too. But I wonder if the shear number of plugins is both a strength and a weakness for WP (especially if module conflicts are frequent).
I think you just experienced a major type of problem for WordPress plugins. A lot of WP plugin developers seem not make any effort separating their front end functionality form the backend, and they just load their javascript or css on every single page, regardless of the need to have Share Buttons in the admin interface.
In my experience, drupal modules do more generic things whereas WordPress plugins tend to be very specific. For example (in Drupal 6 terminology), CCK module let’s you add fields of many types to any type of content, so to make an image gallery you create a new content type and tack on some Imagefields, then use Views to handle many different options for displaying those nodes. But in WP, you’ll find 40 different plugins that each contain all the functionality of an image gallery in themselves, and all work in whatever way that plugin developer decided to implement it.
Maybe a better way to describe it is that drupal modules tend to be tools for creating a feature, where as WordPress plugins tend to be an entire feature.
If this was drupal, I’d say ask the Share Buttons plugin developer to prevent js loading in the admin interface (or submit a patch). But since it’s WordPress, I’d say just go download a different Share Buttons plugin, there are probably at least 15 of them, and hopefully at least 1 dev decided to be picky about loading the js.
So in my opinion, yes, expect more conflicts w/ WordPress plugins (and even wordpress core), but the trade off is you’ll have many more plugins to chose from.
WordPress has a lot more plugins than Drupal has modules. This is by decision: WordPress has always wanted to keep the bar for contributing as low as possible. I believe this is the way to go. If you want to release a module, you just release it, and people are free to use it as they will.
In Drupal there is a quality bar that all modules must meet to be accepted into the official repository. This creates a situation slightly similar to what communist countries experienced with their top-down system, although Drupal core team does not actually plan what modules are accepted or not. Everyone’s free to submit their own, but if it doesn’t meet the quality criteria that core team has seen important, it doesn’t get accepted, and users won’t get the opportunity of using it regardless of what the core team saw as flaws.
Instead of having a strict check for module quality before accepting, I think it’d be good to have some tests for module/plugin quality, and then show those results in a suitable place. Eg. have wordpress.org plugin repository display the results of the tests of http://wordpress.org/extend/plugins/wp-plugin-security-check/ for each plugin. There’s a similar one for themes.
Something that could take even shorter time to implement would be creating a better series of documentation on how to properly create WordPress plugins, and make it officially recommended. It’s hard to make a definitive work though, since people approach creating WordPress plugins differently (rapid prototyping and fix-the-nuances later vs. engineer it completely on paper first). There’s also a wealth of information to know, so the trick is in finding a good balance for what are the really crucial things all plugin developers should really follow, no matter what.
If someone with suitable WordPress expertise would create the basic package of information in answer to that question, I might have time to contribute on writing it into an easily digestible form. Interested, Daggerhart? 😉
Ha :),
I agree Daedalon, but probably don’t have time. I’ve read through at least one WordPress Bible (mostly about setting up your own site), “WordPress Plugin Development”, and probably half the Codec, and I still don’t know what’s going on most of the time. Some documented stuff changes in minor version releases, but documentation doesn’t get updated, while other documented solutions don’t work at all. So I just make whatever plugin I want to use, and put it in the plugin repo just so I can easily update my own sites ;). I consider my plugins mostly ‘personal’, but don’t mind fixing problems other ppl experience as I have time. This is probably not the best mentality to have, but it’s the best I have at this point.
One interesting trend I’ve seen in WP though is the super-themes. There are a lot of ‘Pro’ ($) themes that offer query building, slideshows, and other crazy js widgets all through shortcodes. With that kind of fuzzy delineation between themes and plugins, I’m not even sure what is what. Seems like shortcodes are the single most important feature in WP due to it’s flexibility and ease of use. Chances are I’ll drop widgets and pages from this plugin eventually and just provide better shortcodes for users to put inside WP’s default widgets and pages. In hindsight, it doesn’t make sense that this module has custom page handling when a shortcode on a normal WP page could be easier for a user and better within the system.
Good points, especially about the shortcodes.
The only downside I see with shortcodes is that if you turn off a plugin, the shortcode will show to the end-users. I’d prefer if shortcodes were implemented so that they were never shown to end-users.
Excellent, thanks khromov!
