WordPress rocks! (Most of the time…) Sometimes though it can make you want to pull your hair out. Today I want to talk about that. Those times when you wish you could take a machete to it. I’ve had my share of such situations several times in the past.
Now, I don’t mean plugins, or themes, or anything external like that. I mean the core of WordPress itself. Sometimes it seems WordPress just comes up short. It can be anything from a simple little inconvenience to a total show-stopper.
I think hearing peoples gripes about WordPress would be a nice contrast to the almost constant good things you hear about it. It might also help to get more attention on the issues. Don’t forget that someone may come across this post, read a gripe, and possibly provide a solution. We can all help each other!
So, lets get it started…
One of the issues I always seem to run into has to do with the way some core functions output their code. A lot of the functions in WordPress provide a method for either outputting the code (echo) or returning it for you to handle and probably eventually echo yourself.
Unfortunately not all functions currently in WordPress are like this. Some only allow for echoing the code. This can be quite the inconvenience for some of us. The only way to usually get around this is to capture the output with a buffering function (ick!) or to copy what the function does into a function of our own to do what we need. However, this is less than ideal. What if the core version of that function changes some time in the future? That leaves us in a situation where we have to also update our version of the function. That’s not very nice…
An easy fix? Probably… Will it be addressed in future versions of WordPress? I hope so! Is it a critical issue? No. But, not all WordPress gripes are. This is just one of those things that has bugged me for some time.
So, how about you? What bugs you about WordPress?
> Some only allow for echoing the code
Can you provide some examples? Then maybe, it can be fixed.
Well, I can’t seem to find my file that had my notes on this but I do seem to remember get_search_form() giving me pain before. I was just looking through general-template.php (which contains the get_search_form() function) and it looks like a couple other functions in there echo things directly with no arguments to allow otherwise as well.
If I find that file I should be able to cite some other examples. I’ll post back when I find it.
edit_post_linkandedit_comment_linkare two major functions I wish had anechoparameter. Based on other WordPress functions, one would assume theget_edit_post_linkandget_edit_comment_linkwouldreturnthe HTML-formatted link, but each just returns the URL.Yep, I’m with you on the edit functions. There are a few others I have run into before. In particular I think previous_post_link and next_post_link only echo?
Weird as I think next_posts_link and previous_posts_link both have ‘get_’ alternatives.
Well -an example of echo only….. the widget design means that the widget functions for example, are expected/required to echo out the output. So unless a widget author also provides a shortcode, the code is not easily reusable in other situations.
I wanted to use some great widgets but within a page not in a sidebar. I ended up writing a simple “shortcode_any_widget” plugin which does exactly what James describes – ie : traps the output of the widget function so that it can be used in a shortcode. Thus that page or web is not dependent on a theme template.
Much of wordpress is cleverly designed and allows a lot of flexibility, but it seems that there was a “gap” here.
anmari, do you want to have the widget inside the content or before/after it?
If the later, simply edit your theme file (single.php or page.php) to include another widget area before/after the content:
dynamic_sidebar('after-content');and append this to functions.php:
register_sidebar(array('name' => 'after-content'));Alternatively you can create a new simple shortcode that places widgets of a particular widget area inside the content:
// Use: [widgetarea name="widget-name"]
add_shortcode('widgetarea', 'insert_widget_area');
function insert_widget_area($atts) {
extract(shortcode_atts(array(
// specify the default widget name
'widget_name' => 'inside-content'
), $atts));
return dynamic_sidebar($widget_name);
}
register_sidebar(array('name' => 'inside-content'));
To limit which widgets appear on which pages/posts you can use either of these plugins: Widget Context or Widget Logic.
Hi Kaspar,
the idea behind the “shortcode any widget” plugin was to do exactly your simply “create new shortcode” but generically – ie once you have the plugin installed, you can insert any widget in a page – even multiple widgets. IE: one could create a sitemap for example on any page with out needing to edit or create a template file.
It seems to me more and more non-coders are using wordepress, so I try to avoid having people needing to edit theme templates or php files.
Using a shortcode plugin means it will work NO matter which theme is being used or switched to – ie: a separation between content and style.
the_author_link, the_author_posts_link
Both don’t have an alternative that doesn’t echo.
not hesitating…
This is one thing I don’t like, for example the get_the_category function. This is the member variables…
cat_ID
cat_name
category_nicename
category_description
category_parent
category_count
Why use both “cat” and “category”?
Backwards compatibility.
Maybe deprecate it at some point?
Just found yesterday why WordPress doesn’t always rocks. I am a HUGE fan of WordPress but sometimes I get problems that drive me crazy like the one that started yesterday. After installing a plugin I started getting a white page after I do every action in my blog. I upload a plug, I get referred to a blank page. Same with post preview, page preview and so on…
Bummer!
Did you try removing the plugin? My guess is that this is more of an issue with the plugin than an issue with WordPress.
My issue is with a default install when you go to write a page or post with my host your site can get suspended if you stay in the write screen for an hour so I try to do my writing offline as much as possible as I don’t want to take down my entire account just to post to my blog.
As a reminder, bug tracking for WordPress is here :
https://core.trac.wordpress.org/
that page provides a lot of information !
Personally, i would love WordPress admin pages to be build as plugin admin pages, providing a stronger plugin api.
I would love it if the WordPress import/export file included blog settings, like the front page, permalink settings and media settings. With a typical site, I have my local development site, a staging site plus the production site — that makes for a lot of little settings to tweak.
I recently became aware that switching between the HTML and Visual editors will delete the iframe code that Amazon Associates uses for its Enhanced Display ads. So that’s pretty obnoxious. It basically means if I ever revisit a post that included that code I have to insert it again.
This really IS a pain. I try to remember to first go to a non iframe post and switch to HTML mode, then go to the iframe post. This preserves the code. I also make sure I have the iframe code safely in a text file somewhere else as a precaution. I sure wish somebody would fix this in 2.9!
See this link on why that’s the case:
http://core.trac.wordpress.org/ticket/9874
Also, there’s the Embed Iframe plugin.
Thanks for the explanation and the plugin idea. 🙂
I think I understand that, thanks. Also, thanks for the plugin, my searching had previously failed to come up with anything for that.
Thanks for pointing out the Embed Iframe plugin. I’ve been using WebFrame for a few years, but it’s nice to have alternatives.
I would very much like to see media entries be given the option of having tags and custom fields, much the way posts do. I know there are plugins that can achieve this, but I don’t think a plugin should be necessary since tagging and custom fields are both part of the core setup already. Further, media entries are stored in the database in the same table as posts, so there’s no reason (that I can think of) to prevent the addition of tags and custom fields to media entries.
This single limitation has frustrated me on several occasions.
My other frustration echos Dan above – switching from HTML to Visual editor, wordpress changes things. Not everything, but enough to make it very annoying – if I’ve gone into HTML and coded things a certain way, I do not want wordpress to second-guess me.
Cheers!
What’s interesting is that this point was raised two years ago and still hasn’t been implemented:
http://wordpress.org/extend/ideas/topic.php?id=437
You have to realise that most users _can’t_ be trusted with their HTML. 😛
I just read through that thread gestroud linked to and there’s 10 pages of people with the same complaint – for two years?! Sheesh.
There’s some mighty good suggestions too, like making it a function you have to select in settings first, to ‘enable’ it. But why bother pretending you can edit html if it’s just going to go and mess with it for you? At least they should call it ‘beginners html’ or ‘limited html’ or ‘crippled html’ so as not to confuse.
The best comment in that thread was ‘it should let me shoot myself in the foot if I decide I need a hole in my shoe!’. 🙂
See my proposal: Trusting users with their HTML
Stephanie: The answer has been basically the same for those two years. If you don’t want the visual editor, then *turn it off*.
You can turn off the TinyMCE editor on a per-user basis. So if some users want it, then they can have it. If other users don’t, then they don’t have to have it.
Yes, if you switch to Visual, then it’s going to mess with your HTML. Why? Because that’s the whole point of the Visual mode: to write your HTML for you. If you don’t want it messing with your HTML, don’t use the Visual editor at all. Voila, it won’t get messed with. And the internal automatic formatting can be disabled on the Settings pages, if you are insane enough to not want to use P tags or something crazy like that.
Otto: Why does it have to be All-or-Nothing? I don’t want to ‘never use visual again’, I just want the visual editor to not screw with those instances where I have used html.
The visual editor is fine for probably 95% of the time. But if one switches to HTML then it’s for a reason. If that meant that you were unable to switch back to Visual *on that given post* then that would be acceptable. But as Paula has mentioned above, you otherwise have to go to a different post, go into HTML mode, then go to the one you want to edit.
Abolishing the visual mode is not a good suggestion, merely an easy suggestion.
If you could checkmark given posts (or pages) to be html-mode only then that would be fine too – then you wouldn’t have to dance around with the modes before going to a ‘sensitive’ post/page. Or forget the checkmark, if it would just remember what mode I was using on a per-post basis, that’d work too.
It just seems like it shouldn’t be a crazy request, to have wordpress respect the html when a user has chosen to write it.
This may not be the right forum for this but yesterday I tried to use a database backup file previously produced by the WP admin backup function and found that it contains a lot of duplicate entries. I verified that the database itself does not contain the duplicate entries. I then used the phpmyadmin export function and got a good sql file.
You should probably take that up with the author of the WP-DB Backup plugin. It’s not a feature in WordPress Core.
I just discovered that if I Cut and Paste an image in the visual editor (to change position in the same post), all my custom CSS classes for that image disapeares, along with the wordpress added ones (like align an such). Very annoying when I have to re-teach my customers how to add “no-border” class and such in the advanced options every time they move an image.
Not sure if WordPress can fix that, since cutting and pasting is handled by the browser.
It would be nice if the WordPress categories again supported sub-categories with the same name (and slug). This support disappeared with WP 2.3:
http://trac.wordpress.org/ticket/5034
Not a code issue, but I wish it were possible to use the automatic upgrade features when the files are not owned by the same user/group as is running Apache. An increasing number of hosts have their environments set up this way; very few offer the option to change it.
I had this problem too. Not respecting (or being more strict than) the filesystem permission settings patronizing and annoying.
I just started doing heavy WordPress work a couple of months ago, diving in and learning a lot. I’m much happier doing Perl work, so I admit I do have a personal bias against PHP. That being said…
WP has many good points. It has a lot of hooks and much of the code is easy to follow. It’s a very hackable code base. That last comment could be taken as damning with faint praise, but that is not my intent.
I’d like to share my experiences in deploying WP to hundreds of domains, and managing them.
1) Some of the database indexing can be improved. I made a few tweaks, which I can share for whomever is interested.
2) There is a LOT of documentation, but the quality is very mixed. The documentation is fairly comprehensive but there are many holes.
3) The first thing we noticed when we lit up hundreds of sites at once on a single box was a serious performance problem. Our site was hammered by Google and our own wp-cron needs. Pretty quickly we got a second server to split up Apache and MySQL. I also customized configs for both based on a lot of research. And I still have questions on that (below).
4) The XMLRPC API docs only cover the WP-specific calls. It links to the other APIs it supports, but given that the other APIs are largely static today, I see no reason why WP doesn’t include local versions. The docs for these are even worse in some ways. They’re formatted as blog posts and take more than a cursory review to follow.
5) A huge performance problem was the way WP deals with scheduled events. It has a huge amount of overhead for highly trafficed sites. There were plenty of search hits on this problem, but NOT A SINGLE LINK TO ANY SOLUTION THAT WORKED! I finally had to read the code to find that there was a single define to add to wp-config.php and the problem was solved. The solution was easy, FINDING IT WAS HARD.
6) Also, even now I am not 100% certain that I have disabled things like theme and plugin version checks. Can someone enlighten me on this?
7) Even more importantly, can someone tell me how to invoke wp-cron.php manually?
8) Regarding Apache, I have the traditional Apache and prefork MPM module, running on Linux. (Arch Linux to be exact. If you have any questions about Arch, I can try to help. I’ve been using it since 2004.) Can someone tell me if a different MPM might help performance and memory usage? Or a different HTTP server? Or perhaps something link a reverse proxy. I have 3GB of RAM and it’s now strictly running Apache and little else. How many processes handling requests should I be able to get?
9) Another performance problem is API calls have a huge overhead. Is there a way to propose XMLRPC API changes? A way to execute multiple APIs in a single call we be a huge help. As would some increased consistency. Tags and categories get very different treatment at the API level or identical treatment when not warranted.
10) Not a performance problem, but also about the XMLRPC API, there’s NO WAY TO SCHEDULE POSTS IN THE API! This is a huge glaring weakness. Now, there are ways around this, using direct database queries. But I shouldn’t have to resort to that. Also, the post API should have a way to overwrite an existing post, rather than create a new post with a tweaked slug.
11) Finally, about the schema. The basic schema is well-designed and simple. There are some confusions and problems. It seems out of the box that WP can have duplicate meta records for a single post, or duplicate options. However, the non-standard way that WP encodes structures is *lame*. I understand not using XML. But not to migrate to a more widely-used standard like JSON or YAML is just ridiculous. PHP has native calls for JSON! Parsing and modifying the data is just absurdly hard. I write my tools in Perl. I’ve written or customized plugins and widgets. Obviously, in plugins there is no issue.
12) A lot of debris accumulates in the wp-options table from plugins that were experimented with but subsequently abandoned. It would be great to be able to intelligently clean that up.
13) Insertion of and tags when not in visual editor mode, after a plugin call. Some embedded plugin calls in a post that begin with (no spaces, of course) have or inserted after by WP. No way to turn that off. See http://wordpress.org/support/t.....?replies=9
14) In the WP forums, show the date posted in a clearer way and the last comment date to indicate some level of “freshness” for a search listing. Example: http://wordpress.org/search/sidebars?forums=1 The topic number tells me nothing about how “fresh” the comment is. Maybe some kind of icon to the right of the wordpress.org/support/topic/223232 post: MMDDYYYY last: MMDDYYYY Open/Closed/Resolved
15) One final problem I have experienced. Not WP-specific, but maybe you can help. MD5 gives identical results in Perl and PHP. But SHA1 doesn’t.
16) And, again, finally (really!), we had problems at some point because of the way PHP resolves soft links when using __FILE__. It broke some plugins. Can someone provide a workaround to not resolve soft links?
Regarding your own example, I have also seen the echo/string difference. And I sympathize.
My intent here is solely to provide detail and assistance, not to critcize. WP is in general a very nice app. And the large ecosystem around it has helps us immensely. Thanks!
Now that’s a long comment.
1) it would be really helpful to open a ticket on Trac and put the patch there for consideration.
3) you should be using the WP MU.
6) there is a plugin for each: Disable WordPress Theme Updates, Disable WordPress Plugin Updates
11) WP has to work with PHP4, so JSON isn’t so easy to do.
12) that’s the job of each plugin (there are mechanisms in place).
13) there is a way to turn that off. see previous comments by Otto.
16) I can relate. It’s a matter of using real_file_path(), but might cause problems in other places.
12. Believe it or not, there’s a plugin to clean up database options left by other plugins 🙂
http://wordpress.org/extend/plugins/clean-options/
I still can’t figure out how to insert a line break! j/k (kinda)
The one thing that annoys me is that you can’t set permalinks for categories so that the category name does not show up. I always have to get around this by creating pages that perform the same function.
totally agree with you.
There’s a plugin for that: Top Level Categories
I love wordpress. we have standardized on it for hundreds of our sites, and we’ll eventually abandon everything we have that isn’t wp. My biggest gripe, is the need to edit in place on production sites. We’ve written a theme cloning ap that will grab an active theme and create a duplicate so that we can make changes without ruining an active theme. Sometimes i’ll open the them editor window,grab the text and email it to myself before i make a change but these are just silly work arounds. Unfortunately that still exposes my readers to my test theme while i’m working on it.
there should be an active theme and development theme or something similar so that we can safely make changes to an existing theme.
There’s a plugin for that too. Don’t know what it’s called, though.
There’s the Theme Tester plugin http://wordpress.org/extend/plugins/theme-tester/ that does pretty much that.
Not my opinion, of course, but I’ve been told hundreds of times over the years, that wordpress’s PHP code is badly written, bloatware, and uses too many mysql joins. I never did understand what all that meant, I know a little PHP, but not enough to understand how to do Object Oriented Programming or how to do classes in PHP, I can do some basic mysql calls, but I never did know what they mean by “joins”. so I guess my knowledge of PHP is quite basic compared to most. I guess thats why I never got into plugin development. lol but yeah those are the biggest rumors I hear about wordpress, about it using too many joins and the core code being bloatware. I’ve never had any gripes with WP, but ya hear that all the time.
12) Doesn’t seem to be because I’ve never seen a plugin (or theme) briefly disabled then re-enabled that didn’t retain its settings. This suggests to me that settings remain in wp-options. Maybe we need a “Deactivate Plugin With Extreme Prejudice” option?
There’s a difference between deactivating and uninstalling. When you _uninstall_ a plugin, it should clean up after itself.
It seems that most people can have their problem solved if only they take the time to look for the right plugin.
Yep, well, that might be another gripe. I’m a designer, not a programmer, although I’ve learned (partly against my will 😉 )a tremendous amount of PHP from working with WP.
But I think I spend more of my time hunting down plugins for certain functions than any other activity. And then you have to take into account (as a non-programmer), how well-written or secure the plugin seems to be, whether it will be forward compatible, whether it has high enough popularity to suggest it might be maintained for future WP releases, whether it duplicates or partly duplicates some already existing function or plugin, etc.
I sympathize with plugin developers, too. Even the popular ones receive very few donations from users. Open source and free are both great, but people need to be able to make a living from their hard work, too.
So I wish WP would do a better job of promoting the idea of supporting plugin developers. A good standard would be a dollar for every user. I’m not saying to REQUIRE anyone to pay a donation. Just would be nice if it was a built in part of WP to remind people to support developers by donating a dollar (via PayPal) to the developer. A lot of plugin developers would prob. stay in the game longer if they were getting some money from their hard work….
Some of these plugins are so obvious that they should be integrated into the core. As the plethora of plugins increases in number, it will become increasingly difficult to sift through them all to find the one that’s right.
And regarding wp-options cleanup, when I’ve got hundreds of WP sites to manage, I’d love some way of running a plugin through a command line. (No mentions of WP MU, please.)
Wish the admin site had more user friendly, extensible write panels for custom fields. Something like “Flutter” or “Magic Fields” (a recent Flutter fork), but those two plugins, IMO, try to do too much, and also have an approach that clutters up the database.
All I want is to be able to easily create user-friendly custom fields for clients, and be able to tie them to certain kinds of posts or pages. That ability would dramatically increase WP’s use as a custom CMS, and I don’t think it would be a very drastic change to the existing set up. All the functionality is there, just needs to be tweaked a bit. But instead, I’m relying on stuff like “Magic Fields”, and I’d rather not installed complex plugins like that, which have a high likelihood of not being supported in the future.
One more gripe (I have a lot of them, since I love WP and use it so much) — PAGES. They are really just posts, undated posts. I think the nomenclature and functions of WP ought to reclassify them as a special type of post. And let us do all the things with a page that we can with a post (assign categories for example). The distinction between the two seems like a no longer useful distinction, and one that, in fact, gets in the way a lot. Collapse them, and call what used to be pages something like “static posts” or whatever.
Have you tried Custom Field Template? It seems to fit the bill perfectly.
As for pages, the main difference is that they can be hierarchical. That’s a very powerfull feature and the main reason why pages should stay pages.
In fact, I do use the plugin you mention. It’s great.
You make a good point about the hierarchical nature of WP pages. Forgot about that in my rant, and you are totally right.
So they should be distinct, but nonetheless I think pages should have all the extra data that can be added to posts, such as a categories. There are many setups in which you’d want to tie pages and posts together by category…
Actually, Scribu, I am mistaken in my first reply to your comment above. I thought the plugin (Custom Field Template) you mentioned was a different one.
I had looked at that one once, but not closely enough.
You’re right, it looks much more straightforward than Magic Fields (which I *think* adds extra tables to the DB duplicating the custom fields tables), so I’m going to try it. Thanks for the tip.
In my, “darn you wordpress” category – can we get one stable version?
I love the fact that WP is constantly updating and there are tons of people helping to make it better and better, that is awesome!
Sometimes new features are great, (other times new features just slow us down around here – but that’s another gripe)
But with all the updates and upgrades, some months I spend more time updating wordpress installs than I do posting.
I would love to have a core WP that works – no upgrades needed – I’d rather be using 2.7.1 for the next two years if I could be sure it was safe and secure – and only upgrade to 2.8 or 2.9 or 2.81 or 2.82 or 2.83456 if I needed some new plugins or themes that needed new features – which I seriously doubt.
that would be nice. One stable version I do not have to upgrade – please.
Can anyone help me?
I tried to export my blog to a local computer. But instead of downloading a .xml file it is downloading a .php file with 0kb.
Btw , im still using WP 2.8.5. You think I need to upgrade? Or there is something wrong with my WP?
Thanks for this post which opens large opportunities of exchanges.
I totally agree on the notes for the core of WordPress.
Instead to shortly comment here, I spend time to write a post – http://dev.xiligroup.com/?p=1235 – and try to explain original choice and to open the questions for future… ending with example of a template tag.
Happy reading!
Strangely, I seem to come from the exact same place as Scott. I’m a Perl programmer who started a new job and got handed a WordPress blog. Like Scott, my bias is definitely like Scott’s. Anyhow:
1) I found customizing comments to be really quite icky. I was handed a design that I had to skin WordPress with and digging into all that was a nightmare for me. If you ask me how I did what I did, I couldn’t tell you because it slipped from memory as quick as it was completed.
2) Global variables. Everywhere. I get that what makes WordPress so powerful is that there’s a tonne of stuff available in the theme and plugins… but it makes my skin itch. Found it frustrating that I was modifying global variables to get the behaviour I wanted. This could in turn affect things later in the page that I hadn’t intended to.
3) Filters and actions. There’s a lot of ’em… and that’s awesome. Us Perl guys do like to have options. However, the codex’s documentation is sketchy and even third party sites didn’t illuminate a lot. I ended up fishing through the source to see if the filter/hook I was looking at was what I needed.
4) Load-balanced servers. I had to deploy the blog to load balanced servers… not fun. Issues with having it available on domain names for both the individual boxes and responding under the fully load-balanced domain name wasn’t a complicated fix… just had to figure out how to do it. Because I couldn’t allow users to upload files to the file system, I actually wrote a DB-based media plugin and serve script for this. It’s got a gallery, shortcodes for posting the images… the whole nine yards. Yipes. I’m shocked that I could find very little information on deploying to this kind of environment. Is this when people just say, screw it and go to wordpress.com instead?
5) I guess 2 and 3 really feed into this. I wish I wish I wish WordPress was architected using the MVC pattern. It wouldn’t be the WordPress all know and love… but that’s a system I’d love to hack on.
2) The global variables are due to PHP4 requirement.
4) Care to release that plugin into the wild?
2) Respectfully disagree. That’s a matter of how they architected the system. They could have chosen more of a templating route and a more abstracted plugin architecture. That being said, I recognize that one of the things that made WordPress so successful was the batteries included approach.
4) It’s been discussed at work but it’s heavily integrated to our environment right now. It may well happen though, we’ll see.
I’m nowhere near as technical as you in my understanding of WP, but I have been annoyed at the limitations of the post by email functions. Primarily it ticks me off that WP strips out links when posting this way. I want to be able to post my content to my blogs with links intact. Unless I’m missing something and there’s a way to do that with post by email. I just need to add that little bit of automation to my processes but maintaining links is essential.
my $.02