Disclaimer: I am not a plugin author. This post is filled with my own opinions and is taken from an end user point of view. If you are a plugin author, be sure to add your point of view in the comments.
Traversing through my feed reader after a major version of WordPress is released is always interesting to me because I’ll never know what types of reactions I’ll find. Unfortunately, I’ve been noticing a trend that is unacceptable. The basis of this post will be focused around a line of thought which I find to be anger inducing.
The biggest problem lies in the fact that WordPress is continually pushing updates too often without much in the way of testing with the most popular plugins. Podpress is huge! how could they have released 2.6 without seeing if one of the most popular plugins will work? To me the fault lies in WordPress updating too soon. As I am on a hosted install of WordPress, I can’t roll back, so now I am stuck. From now on, I will clearly be waiting at least two months before pushing any hosted updates of anything WordPress related! – Comment Written By Jason Of Canonblogger.com
This is the type of comment I’ve been reading lately on blogs which discuss the PodPress incompatibility issue. Time to break this line of thought down. First off, lets take a look at this years timeline of WordPress releases thus far.
- Version 2.5 / March 29, 2008
- Version 2.5.1 / April 25, 2008
- Version 2.6 / July 15, 2008
- Version 2.6.1 / August 15, 2008
- Version 2.7 TENTATIVELY SCHEDULED FOR November 10, 2008
By looking at the release dates for actual versions used by the public, we can see that at one point, two full months went by without a release. Further that with the fact that a maintenance/security release follows a major release one month later. WordPress is publishing software which is extremely popular and this popularity has its pitfalls, mainly with security as the popularity of the platform makes for a nice target. Would you rather WordPress release updates twice a year? What happens if a major security vulnerability is discovered at the halfway point between releases? Would you want WordPress not to deviate from their release cycle? As far as I’m concerned, I’m pretty happy and relieved to see the WordPress development team up on their game, releasing updates to the software multiple times per year. With plugins such as Automatic Upgrade taking the pain out of upgrading through FTP, I don’t understand why the number of updates per year is such a hassle.
One of the statements in the comment above describes the fact that the WordPress team must test out the software with the most popular plugins before releasing it to the public. Since when did the responsibility of testing every plugin known to man for WordPress fall on the shoulders of the WordPress team? The answer, never! In a recent post written by Lloyd Budd he happened to write a statement which I whole heartedly agree with:
I see the Automattic team as the WordPress guide. WordPress is completely community created and supported. Automattic takes on the big (scalability) problems that the community doesn’t have the resources for like: providing the free WordPress.com service and funding usability testing of a new WordPress dashboard experience.
Based on what I’ve seen, what happens with plugins and their compatibility to WordPress is outside of the teams control. I hate to pick on PodPress in this post but it makes for a great example. Before WordPress 2.6 was released, it went through three different Beta releases with one release candidate. The first beta release happened on Monday June 23rd, 2008. The actual release of 2.6 occurred on July 15th. That makes for a total of 22 days which passed between the first beta and the actual release. In my opinion, 22 days is plenty of time to figure out if a plugin is compatible or not. Granted, there may be personal issues, lack of time, or some other reason why the plugin author has not updated a plugin. Suffice to say, a plugin not working lies on the shoulders of the plugin author, not the WordPress development team.
PodPress is a special case in that the WordPress team actually created a patch for the plugin and then sent it to the plugin author. This was reported by Matt himself on a post written by David Peralty. Apparently, the patch never made it to PodPress and to this day, the plugin is incompatible thanks to an issue with the post revision feature. Matt did comment on the fact that there is not much they could do except commit the code directly without Dan’s permission.
Conclusion:
The bottom line is this. WordPress has a good release cycle and in my opinion, provides plenty of time for plugin authors to test their plugins with the newest version of WordPress before the public gets a hold of it. My opinion is that, the WordPress team can not and probably will not take it upon themselves to insure that all major plugins work correctly with current/future versions of WordPress. So the next time you upgrade WordPress and realize your favorite plugin is broke, don’t blame the WordPress team, blame the source.
what wordpress does for the blogging community is amazing, just imagine a world without wordpress…huh?..huh? scary!!!!
I partially agree with you and partially disagree with you. The part that I do agree with you it is obvious when a release is available for download it has not been thoroughly tested and there are a lot of compatability issues. The biggest complaint about WordPress that I have there is not enough testing which includes compatability testing.
Where I disagree with you is in regard to plugins. From my experience most plugins are not worht using. I find if I download them and then install them many of them do not work this is quite typical of the plug-ins for stats and those that claim to optimize your blog for search engines. Even worse I had one that cause problems with my database that resulted in me loosing about six months of work. For me I am one who believes that WordPress should do away for most of the plugins, incorporate a lot of them into their theme, and make a few available that adds an enhancement to WordPress. By using this approach they can have a better control over WordPress, minimize bugs, and ensure compatability.
You can’t blame the WordPress team for a lack of testing before an initial release. As the article shows, they generally always have beta/release candidates that are supposed to be used for testing before the public gets a hold of the new version. Perhaps the issue is that not enough people are willing to beta test the new version and instead, we end up with a small pool of beta testers that are severely outnumbered when compared to the amount of people who download and use a version when it is released to the public. And coincidentally, most of the bugs are found during this period, giving WordPress a bad wrap. If all of the people who used the final version participated in the beta test period, you and I would end up with a much better product.
As for your second argument, it is not the fault of the core WordPress team that a plugin caused you to lose six months of your work. It was the plugins fault. While it would be nice to have WordPress come bundled with all of the plugins you use, your user case is probably not the same as others so the WordPress team has to make careful considerations for when to include a plugin into the core or not.
You lost 6 months of your blog because you do not regularly backup your database, and NO OTHER reason.
I use the WP backup plugin to email me a complete backup of my database every hour.
Every hour? Isn’t that.. massive overkill? Or did you mean every day..
You might think it is massive overkill to backup every single hour, but I have the benefit of EXPERIENCE here.
It’s not just posts, it’s also COMMENTS that need to be backed up.
If you only do a backup every day and your system crashes, you could lose 23 – 24 hours worth of comments.
If you do it every hour, you can only lose an hour of comments.
My backups get emailed to my gmail account. I have a filter which automatically sends them to trash where gmail automatically deletes them after 30 days of lying there.
If I ever need a backup, I just go and get the last one out of trash.
Good point. Basically any updates or comments need a backup. Then the question is what is ideal backup. We can borrow concepts from RAID. So a instant mirror (not public or even indexable) on a different server may be ideal. Also backups can be differential.
Do you post 10 articles every hour? that’s why you need to back up your database so frequently?
Plugins are good complements for wordpress, there will be always good and bads, some of them will work some not. I agree with the post, do not blame WordPress for plugins that do not work. Blame WordPress when it has security bugs like old versions. They should test all new versions at least half a year to reduce potential risk. But what can we do? the software is free.
This argument reminds me quite a bit of the old “Microsoft should do more testing of Windows to ensure compatibility” and “{Program Name} sucks on Windows because of Microsoft, not because of {Program Name}.”
One could argue that the fault lies with the people who use WordPress and the various extensions, because so many upgrade their sites without first testing the compatibility of their favourite plugins 😕
You should use MT. They have all that crap built in.
Just one small point taken right from the start: there is a difference between issuing a new release (such as 2.6) and an update (such as 2.6.1). Too many main releases tend to exasperate many users, two or even one major main release in a year would be fine for most. The updates are a necessary part of the process which correct security issues and problems with main releases and don’t, to my way of thinking, count as a main release but a good move to correct faults and, given enough time and consideration, tackle problems where certain plug-ins are concerned.
> Would you rather WordPress release updates twice a year? What happens if a major security vulnerability is discovered at the halfway point between releases? Would you want WordPress not to deviate from their release cycle?
Blah. WordPress could easily have a security branch and a features branch, and do an arbitrary number of security updates while staying on a feature-releases schedule. That is simply to say that your particular argument here is complete nonsense; I am however happy with the release schedule, I don’t want it changed. Certainly there’s plenty of warning for every release for plugin authors to fix it – and, in this particular case, that the plugin author did not even bother to apply a fix he had been given is clearly his fault.
I agree totally, when wordpress releases a security update or even a new version, then this is done for our best. Security risks are found all the time and most need to be addressed immediatley otherwise the wordpress user starts complaining about how his blog got hacked. No matter how air-tight the wordpress creaters think releases are there will always be the people to test it to the max and find these errors, which in the end is a good thing for you and me. Stop complaining people, its for your own good!!
I don’t know about branch this or branch that but it sounds like a good idea. But if it’s something that could so easily be done, why hasn’t it been?
Yeah exactly.
That point about security and new-version cycle is ridiculous.
Like every other modern software they could do just a new major release every year (or every 6 months if they really want to go fast), and then just push security releases when it’s needed for the existing stable version while committing new features to the development version.
Bah
From my experience using plug-ins I feel some of them are hastily written and not thoroughly tested with WordPress. From my perspecive I do feel WordPress can do more in ensuring quality of plug-ins by establishing minimum quality standards. Such standards can include a minimum number of downloads in a given period and if that is not met then the plug-in is pulled. Also another standard could be number of ‘bugs’being reported and the severity which means too many or too sevre then the plug-in gets pulled. The point I am trying to make is quiality is important and standards can be established. While you are right to argue in your ‘Conclusion’ not to blame WordPress I do feel WordPress can do more to ensure the quality of the product the better testing and establishing minimum quality standards.
Chuckles, I am right there with you. I have had a few different conversations with Matt involving the issue of having a strong set of coding guidelines or practices to which a plugin would not be allowed to be hosted in the plugin repository if the plugin did not meet their criteria. However, to pull this off, you would need some seriously dedicated individuals to go through each plugin, sort of like a verification team. To learn more on how WordPress could accomplish this, look at the way the PHPBB3 team handles mods for the version 3 branch of their code.
Shorter Post For Certain Plugin Authors
Your arm broken?
WordPress does more for plugin authors than many, if not most, other publishing platforms ever do.
I wrote some plugins over 5 years ago now that still work. That’s something like from version 1.5 to 2.6. That’s simply AMAZING.
I have ZERO complaints about WordPress release cycle or their lack of testing every conceivable feature.
It is the responsibility of the Automattic team to release a stable, solid base. It is the responsibility of the plugin authors to accept and acknowledge compatibility issues or fix them, and in very important addition, it is the responsibility of a provider or user to TEST UPGRADES BEFORE DOING THEM.
Nicely said.
(As a side note, and feel free to delete this comment after reading, it would be great if you could give the P tags their top and bottom padding for the comments. 🙂)
Better?
Much.
Thanks.
🙂
Also don’t forget that not only do they put up beta and release candidates, anyone can download trunk from svn and test for bugs and incompatibility at any time.
This issue almost sparked a similarly long post which would of discussed the fact that if the number of people who downloaded and use an official version of WordPress would participate in the beta releases to find bugs and report issues, think about how much less of an issue compatibility and bug squashing will be. I guess in the end, beta testing or having a second install of WordPress is too much of a pain in the ass.
Maybe making system where people can easily test with trunk/beta releases could help. Something similar to how people will setup demos of WordPress pre releases so people can get an idea of what is coming along. Make it so people can have a WordDress install of a test version setup for them for maybe a day and they can test plugins and features on it. Also the bug reporting could be easier for normal users who might spot bugs on this. Sometimes trac can be intimidating.
I have no complaints about WordPress. Time on time, the WordPress team manage to dream up new features to make our life easier, and plugin issues, unless Automattic wrote them, can’t be their responsibility.
I’m not a plug in author, but I do use WordPress and several plug ins. I’m a developer by profession [not sure if that matters] but it is my opinion that whether plug-ins work or not is up to the user doing the install. Not the the WordPress team.
We use versions in software to help identify what will work with what.
The WordPress team can not be responsible for Community Developed Content — such as Plugs, themes and the alike.
Regards All,
Frank (understandingGuitar.org)
Frank that is the overall issue I tried to represent in this post.
The problem is somewhat difficult to state well. There is always an issue with users not testing beta releases and that is partially the fault of the developers and partially the fault of the users. If more people tested (actual testing, not just using) WordPress, then a lot more issues would be resolved before a release is sent out.
It is partially the fault of WordPress, because there isn’t a long enough beta cycle. Most software debug cycles are two months at the least. If everyone did decide to test WordPress, it would cause an influx of bug tickets that should be resolved. I think at some point the team would just say, these tickets are going to be resolved that affect the majority of users and these will be pushed to the next release.
I’m thinking of an Acceptance Test Suite for September, which should hopefully find issues within WordPress and improve the Administration Panel experience for users. I’m also thinking there needs to be more test cases in the Automattic WordPress Test Suite. That said, the people who do actual testing do a fine job, because it is a hard task. I think it will be easier and consistent if a computer did some of the obvious testing.
What does this have to do with Plugins? Nothing. Plugins should have their own support and quality assurance. If Automattic supported Plugins like Microsoft does, then WordPress would be seriously bloated.
Well said Jacob. Your statement on not enough users not testing beta releases is also a major reason why the official versions of WordPress end up with so many bugs which are discovered AFTER the fact.
“By looking at the release dates for actual versions used by the public, we can see that at one point, two full months went by without a release.”
Which pretty much makes the PodPress point above…there were two whole months without a release in 2008 so far? That’s a very aggressive release schedule.
It also doesn’t help that WordPress devs tend to make major changes to the underlying architecture of WordPress on a regular basis (which is the real problem — the extent of fundamental changes, not the frequency of new releases). It leaves the impression that they don’t really have any long term idea of what they’re doing (or to put it a different way, they seem to be constantly making major changes for short term reasons without actually having thought about the long term).
Plugin makers need to keep up with most new versions of WP by testing their plugins on the latest beta versions of WP. When the final release of WP is made, the plugin would have jack all incompatibility issues.
Martin,
It’s not that simple. I’ve written 6 plugins, so with every major release of WordPress, I need to test 6 plugins and often make small changes. That takes time.
I’m not being paid to write plugins. I’m doing it partly because I want to and partly because I want to give to the community. I have a busy full time job, a family, a couple of blogs and some other projects, so keeping up with testing isn’t always an option.
I agree that the responsibility for testing is with the plugin authors, but people have to understand we are volunteers.
In general, I’d like to see only two major releases a year. It would make it easier for plugin writers, easier for the average blogger to upgrade, etc. There’s no problem with other minor releases for security reasons as these are much less likely to break plugins or people’s systems.
I’ve been giving the argument of less major releases per year some thought and I am beginning to side with the argument that perhaps there should be 2 at most, major versions released per year. WordPress 2.4 which was skipped due to time constraints afforded the team a few more weeks/months to work on 2.5 and it seems like the upgrade from 2.3 to 2.5 went smoothly when compared to other upgrades. Perhaps there really is something to be said about tuning down the release cycle a bit.
My sentiments are that as soon as you have got a new feature working, you could release that.
The problem that people are really throwing up, I believe, is that upgrading is a shlep, especially when it’s done manually, so perhaps that is the thing to address – making updates easier to do via some automatic process. I believe there is a plugin to do that already, though, but I haven’t checked it out.
I just installed subversion on my server and set up a bleeding edge “sandbox” blog, and that process seems simple enough.
Unfortunately the trend I’ve noticed in the last year or so is that with each major release of WordPress (2.5 and 2.6 are classic examples), even though the team do core testing they still miss a bunch of critical core issues/bugs that cause chaos amongst end user sites. It usually takes until the 2.5.1 or 2.6.1 release before these issues are fixed (such as permalink chaos, permissions, image uploader issues etc.)
This is not plugin related. It’s core WP functionalit which really does deserve to be tested to death before being released into the wild.
Don’t get me wrong – I appreciate it’s open source and I also appreciate it’s a huge amount of development and testing effort (in a distributed sense) that goes into these releases… but I’ve come to the conclusion that although I love the WP software I will never ever again update my sites on a major release. I instead prefer to wait the two months until the .1 release is produced to patch the inevitable core issues in the major release in question.
This is borne from bitter and hard experience of too many issues during upgrades and I know there are a lot of other folks out there too who feel the same way.
So in summary (too late I hear you scream!!) – more testing, less releases please. Concentrate on the core.. and if the testing period is longer the plugins can also be tested in the same tranch.
You raise some interesting points and I’ve picked up on the same trend as you. Many people appear to be waiting for the .1 releases before they upgrade their site. If this is what the major trend is, does this speak volumes for how bad upgrading to a major release is or can be? That is not a good sign.
Anyone who is an authority in WordPress tells end users to upgrade their blogs as soon as a new version is released. However, if a blog that is upgraded provides more difficulty/problems than just by leaving it alone, why bother? I think that is the attitude a lot of WordPress blog owners are taking and that is a disturbing trend.
Hey Jeff,
It is indeed becoming a trend and as a long time WordPress user and someone who maintains other WP powered websites for those who don’t prefer doing the “heavy lifting”, I’ve just about come to the point where I’m going to start recommending these folks wait until the first “*.1” release before upgrading. You see, I follow Trac very closely and do extensive testing on each new major update to WP in order to determine performance and compatibility issues with what you might call the “standard” base line plugins WP users might commonly install (and I agree; WordPress drives plugin development, not the other way around).
Case in point here is the latest 2.6 version which caused many users to experience a rather significant slow down in Admin performance to the point where it was tripping PHP quota limitation caps on their shared servers and that’s a whole lot of WP users. This had something to do with a massive lag in SQL query time and response coupled with the number of active plugins (no error call outs in the error logs which made it double frustrating). 2.6.1 solved this problem and it was stated in the release post that this problem did in fact exist and was fixed in this maintenance release although no specifics were offered.
Be that as it may, it may seem to be a disturbing trend but I don’t believe it means that things have to be done any differently. It all boils down to the fact that there’s 1000’s of different setups and configurations that would have to be tested in order to cover “everything” and that task is simply impossible. In my mind it’s up to the WP users to keep their WP powered sites updated to the latest version of WordPress and make sure their themes and plugins are compatible to the extent that they can. Plugin authors (those wonderful people) I’m afraid are responsible for keeping their plugins up to date if they choose to do so. No one is twisting their arm, they volunteer their time and effort. The WordPress team is only responsible for maintaining a light and efficient core to be built upon.
If the trend continues toward waiting until the “*.1” then so be it. If that means that a bit more testing is needed during the development (by the team and/or by others) then that’s up to the team and team leader(s) to decide and what the most effective way to bring about that additional testing might be.
My frustration is that, every time I upgrade after waiting for bugs to be fixed, I still end up getting bit! This time I waited a couple of months to upgrade from 2.2.1 to 2.6. Now my columns won’t line up and my categories have disappeared. 2.6.1 didn’t help. Going through the forums, others have had these issues and NO SOLUTIONS. Using WordPress is very discouraging at times ….
I agree that all the plugin testing should fall on people that use the plugin and plugin authors. WordPress developers can’t test few thousand plugins available. But biggest problem is that they add or change some of the features that create much more problems thet they solve. After WP 2.6, there is no way to make ANY ajax driven plugin work on every WordPress installation if you changed the location of wp-content folder. If there is, then someone needs to tell me what the solution is. Ajax plugins rely on external files outside of the WordPress cycle and without knowing where the WordPress is, there is no way to make them work. That is the biggest WordPress problem, changing some very important features without providing replacement solution.
Thanks for the comment Milan. I have not yet heard of the issue that you present but it sounds like one of those issues which is a pet peeve of plugin authors and the core WordPress team. But hey, if the core team is going to change something that plugin authors heavily depend upon and then not provide a viable alternative, you definitely have a case.
If there has to be an update, then its for a good reason. The hard work people put into making wordpress great and all of us testing and using builds for an exciting future of wordpress.
Yes, there is a good reason – and MOST of the time, it is an update to fix security holes introduced by the previous version! I find the development team’s urge to introduce new features trumping security on an ongoing basis.
Perhaps WP sometimes wants too much in too little time. The Ultimate Tag Warrior worked so much better before this tag system got incorporated into WP. It’s not only about plugins of course. WP comes with new features with every update. Like a new dashboard. Is it really better than the older one? Or a preview of a theme you might want to use. Anyone using K2 has problems with every update of WP. Sometimes I feel WP hates K2. Of course we all love WP, it’s just the best blogging platform there is. It is worth a lot of money as well nowadays. Not only the WP Team, also all these hundreds of plugin authors deserve credit for what they did for WP. For us, ordinairy users, an update sometimes consumes a lot of our time. WP once stated that it is a blogging software to work with and not to fight it. You can be sure I have done a lot of fighting to keep my site right and running. I must confess from now on I will be waiting for a longer period of time before doing an update. Security updates? Okay. But new features simply aren’t.
I use WordPress for three sites, and am currently redesigning them one at a time to use few or no plugins (beyond anti-spam, which I can’t do without). I’m tired of getting the “you idiots need to update” attitude (or even better, the “you deserve to get hacked if you don’t update”) from people who install the releases the day they come out—and the thing that keeps me from doing the same is the plugins.
While releases come regularly, plugin updates are often erratic, or non-existant. For me, the solution is to quit using them, painful though that may be, because I just can’t count on today’s really cool plugin to be available at all when the next version of WP is released.
My sentiments as well. If you look at the history of wordpress, I think the version list alone proves that you are more likely to find a new and deadly security flaw in the next version of WP than any feature you’ll really need or want.
That’s the problem. With the development team, it’s new features uber alles – security comes later with emergency patches and dire warnings.
Considering that history, it takes a lot of nerve (and imperviousness to irony) for them to call reluctant upgraders “idiots”!
I find that with every major release of WP, a few of the features of plugins I use are replicated in the core, reducing the number of plugins I have.
Personally, I’ve never had any compatibility problems between plugins and new releases of WP, except with plugins which I haven’t needed anymore after the new version was released.
I think the development cycle of WordPress is great – I wouldn’t want it slowed. And yes, I am a plugin developer, though so far none of my plugins have been released for public consumption…
As several have noted – there is an important difference between updates (to fix broken or insecure functionality) and the introduction of new functionality. Any software / web service has the challenge of trying to strike a balance between stability and evolving to meet the needs of its’ diverse client base.
Managing expectations is almost as important as managing code – Automattic has already said they are scaling down to 3 releases a year after they found much slippage in schedules when attempting 4. Perhaps (if they don’t already) they could consider prioritizing new / “major” functionality into the first release of the year and revisions to those elements or other minor areas with the subsequent releases.
Well, there’s always the magic and best answer. If you don’t like what the WordPress team does. There’s always Movable Type, that is if you can even get it to work.
Idiots. Give ’em a free product and they complain, must be liberals.
As a plugin author, I don’t mind the functionality improvements… in fact I welcome them. But I shouldn’t have to poke sticks into a black box after every release to figure out what I need to do to keep up. It’s much easier for the core development team to publish something to let us plugin authors know what we need to look out for, than to have thousands of different authors all trying to solve the same problems at once. And, if such a document were a deliverable of each release, there might be fewer issues and a clearer path for plugin developers to follow. I’m still not clear about the correct way to deal with moving the wp-content directory, or how to handle the post revisions, for example.
I think Roger hit the nail on the head: a simple document that plugin authors can reference, advising what changes have been made in the core that could impact plugins.
Automattic shouldn’t have to test each plugin, and I would never advocate such a position. Providing a quick-and-easy reference, however, for plugin authors — the people who, in some cases — help make WordPress a much more inviting platform, whether for blogging, site development, or other imaginative uses. It wouldn’t take much work on the part of Automattic, and would make things, I believe, much easier on plugin developers, and, at times, theme developers, as well.
That would be very helpful. A list of added actions and filters (and what they do or which files/functions they are in), a list of depreciated actions, filters and functions and a list of removed actions, filters and function would be invaluable.
Rather than me having to step through my code and search the WordPress code to check it is still there. It would also be very helpful for improving plugins if you spot a new filter or action that would be better placed to server a particular purpose than one you have used before.
Just wanted to say that I agree with you. WordPress is doing enough just keeping up with the security issues. 🙂
Plugins are nice, but they’re just goodies that we use along with the WordPress software and checking for compatibility might be nice, but certainly isn’t WordPress’s problem. Plugin developers need to think about this burden when they create their plugins and either plan for it or accept that at some point their plugins might become incompatible with WordPress.
I’m surprised more WordPress users don’t remember this when they start adding lots of plugins to their WordPress install.
@ the quoted portion in the post, not the post author:
The biggest problem lies in the fact that WordPress is continually pushing updates too often
Nope. I LOVE LOVE LOVE the fact that WordPress is being continually improved and upgraded.
I CHOOSE if and when I’m going to upgrade. No-one else.
without much in the way of testing with the most popular plugins.
That’s why they have beta and RC releases – for the plugin authors to make their code work with the upcoming new releases.
Podpress is huge! how could they have released 2.6 without seeing if one of the most popular plugins will work?
Not WordPress’ problem. Responsibility for a plugin working lies SOLELY with the plugin author and NO-ONE else.
To me the fault lies in WordPress updating too soon.
We’re not stopping the world so you can get off. No-one is forcing anyone to upgrade.
As I am on a hosted install of WordPress, I can’t roll back, so now I am stuck.
That is just too darn bad. You need to take responsibility for your own SELF-HOSTED WordPress installation.
When I upgrade, I do it manually. I move the existing version to a wp-old directory and then copy in the new code. If something does not work, I can rollback to the intact previous version.
It is MY site and I must take care that if something breaks, that I can FIX it myself.
WordPress does not come with any warranties.
From now on, I will clearly be waiting at least two months before pushing any hosted updates of anything WordPress related!
Maybe you just need to follow a more sensible upgrade procedure, so that if anything breaks, you can just restore the last working version, until such time as all your favourite plugins are all sailing in a line with the latest WP version?
Richard: Not everyone has the technical skills to run their own hosted solution. That’s an unfair attitude. That sounded like something I would’ve heard out of the MT camp.
Fact of the matter is, WP is big, WAY bigger than they probably every one every expected. So, I am not surprised that there are numerous bugs found in major releases. Like Windows, there is just no way to test WP on every conceivable configuration.
BUT, working with some of the larger WP installs, like HOSTS and such, would certainly make it easier to test on a broader ranger of installs.
I manage about a dozen WP installs, and it’s a pain in the a$$ to upgrade them. I do it, but it’s very time consuming. Add on top of that the research on Plug-ins, and THEIR compatibility with EACH version of WP, and it’s a very time consuming process. Auto-upgrading/Update notification helps… but then, things break in one release (like the stupid Flash upload issue), and you spend as much time researching NEW problems, as you do solving the plug-in issues.
And as was said before, you are damned if you do, and damned if you don’t.
If you DON’t Upgrade for some reason, then you have security issues to worry about.
Features I can live without, but security I can’t.
Sometimes, there’s just no winning.
I would prefer a better, more stable build process that favors the end-user developers, and makes sure they are considered.
As far as a backup solution, again, that’s easy to say if you have the skills to do it, but if you blog just broke, and you aren’t a sysadmin, it’s a bit intimidating. I fully understand why anyone would rather wait, then take the chance of upgrading.
Not everyone has the technical skills to run their own hosted solution.
Well, by definition, running your own self-hosted version of ANY software places the FULL and SOLE burden of RESPONSIBILITY on YOU and no-one else.
If you lack the ability then you need to HIRE someone to take care of the technical details or you have to use a blogging platform that takes care of all the tech details for you such as what wordpress.com offers.
If you need to upgrade a lot of WordPress blogs, then you should probably write a script to do it.
I don’t upgrade all my blogs all the time. I don’t even upgrade each time. I skipped right over 2.5.1 to 2.6. I haven’t installed 2.6.1 (yet), but it’s there for me IF I want to do it.
Perhaps we should all be as great as you are. Hip hip hooray! RIchard is the greatest ever!
If you want to install self-hosted software, you need to be proficient or hire someone who is.
Please quit your unhelpful sarcastic attitude. I am stating my opinion. If you disagree, you don’t have to start up the personal attacks.
Personal attack? I don’t believe anything I said was a personal attack.
Richard, sorry, but you have a certain, how shall I say it, “air” to your replies that makes it sound as if you are the only one here with the answers, and frankly it seems as if you don’t leave any room for discussion about it. To me, it seems as if you are saying, either you host at WP.com, or you become a server admin, and learn how to host a website yourself. You leave no room for any in-between.
I think there is a middle room, and that’s the place where WP can help us with a more sophisticated product, that has better upgrade functions built in.
Not everyone has the technical skills to run their own hosted solution.
This was not a statement as in, all of us that run self-hosted solutions do not have the skills to run them. I was saying, that unlike us geeks that spend a lot of time in the WP forums, and in trac, etc, there are a lot of people who just want to blog. And they start out at WP.com, or they get the free blog from their host. They don’t know anything else. They don’t have the skills to host it them selves, nor do they want to. It’s not a self-hosted blog.
To me, it seems as if you are saying, either you host at WP.com, or [snip] you learn how to host a website yourself.
That’s exactly what I am saying. If you manage your own domain account on a server, you need to learn at least how to use FTP, which is what you need to create a directory to retain a copy of the last working version of WP.
If an automated scripted install of WordPress does not have a rollback facility, then probably best not to use it.
I ssh into my server and install WP from the command line. It’s not rocket science to learn a few Linux commands. They’re all documented online. Some people are just too lazy to learn how to make use of readily available resources and tools.
And then when their ignorance and unwillingness to learn these basics bites them in the ass, they whine about how screwed up everything is.
What is screwed up is their unwillingness to put in the required effort to learn how to manage their own domain account.
Well, Richard, here is where I say let’s agree to disagree.
What makes WP so powerful, and such a success, isn’t the number of people who are web gurus and know how to ls -l and chmod 755. It’s all of the people who have put WP to so many uses, posting across the net. And not all of these people fall into the category of being lazy or unwilling. That’s a very cynical view. There are quite a few people that use WP because of how easy it is, not because if forces them to learn Linux commands. These people login to their url/wp-admin, and post a new blog entry. End of story. They aren’t lazy or unwilling. They haven’t got a clue. It’s not their fault they aren’t “computer people” anymore than I am not a graphic artist. It’s just not that easy for some people. Just go over to the forums, and see how many people don’t understand how to modify their themes to enable the widget code. It’s easy for US, but damn near impossible for them.
And how much experience do YOU have? I have over 10 years of web development, 20+ general development. I am not saying that you can’t learn this stuff. I am saying that not everyone can. We all can’t be developers or scientists or mathematicians. I am saying we need to help them. Your attitude is a sink or swim mentality, when perhaps all we need to do is offer a helping hand, and empower them with better software solutions.
It’s not black and white; there is a lot of gray.
I want all of those people to use WP because it’s the best tool, period. I don’t think we should require users to have a Linux background.
We can make the tool better, and aid those who aren’t “in the know”. That helps everyone, you and me included.
If you want to eschew a large segment of people from using WP, then using your approach would do exactly that.
For that matter, perhaps before a user is granted the privilege to use WP, we should just give them a quiz, and make sure they meet YOUR criteria of what a proper WP admin is.
If you want to use ANY software on your own domain account, you and only you are RESPONSIBLE for it. Either you have the knowledge to administer your own account or you learn or you hire someone to do it.
There’s no way of getting around that issue. Because when people who don’t know how run into problems they start blaming the software instead of themselves for failing to take full responsibility for their own problems.
No way you can say otherwise. If you do, you’re just lying to yourself.
For that matter, perhaps before a user is granted the privilege to use WP, we should just give them a quiz, and make sure they meet YOUR criteria of what a proper WP admin is.
You’re being obnoxious AGAIN.
Go educate yourself and READ what a GPL license means.
It means anyone can go get it. It doesn’t mean they have to pass any tests to get it.
But neither does it say they will be able to get it to work EASILY without having knowledge or having someone do it for them.
Why do you THINK Automattic launched WordPress.com?
Because some people don’t want the burden of taking responsibility for running their own domain and all the attendant technical issues.
What we are talking about now is NOT about WordPress or any specific software. We are talking about what responsibility an individual takes on when they register their own domain and host it.
What we are talking about now is NOT about WordPress or any specific software. We are talking about what responsibility an individual takes on when they register their own domain and host it.
No, you are talking about that.
I am talking about understanding that there are many kinds of users that use WP, and your hard line attitude would have them drop off the face of the earth because they don’t know how to chmod. I am not being flip. It’s the way you come across. I want to help them, you want to eviscerate them.
I don’t agree with your general assertion of how “easy” it is to learn linux commands either. It’s not like windows. There is no GUI or point and click. Most people wouldn’t have any idea where to start. You make way to many assumptions about what people SHOULD do or SHOULDN’T do.
If it were up to you, I would have to know how to repair my car to drive it. It’s a crazy assertion.
Why do I have to know linux commands to write a blog?
The main reason, is so they can ssh into their shell, and unzip their wp contents directly on the box? Most people just FTP their files up, so ssh or not, they get them up there… but, then there is the subtle but arcane land of permissions. Explain that to a newbie. CHGRP and CHMOD, etc.
If there is a security vulnerability, it’s a flaw in the CODE. It’s an update that the user is exposed to, not because he wants to upgrade, but because of (car reference again) a recall.
And, if he’s not aware of the upgrade, or he doesn’t know really HOW to upgrade, then it’s a bit of a daunting task.
Again, YOU and I have no problems here, since we know what we are doing. But walk in the shoes of someone who hasn’t a clue, and you might see how this system is setup for them to fail.
I might also say that anyone suggesting that this user take on all of that AND THEN setup a separate site to “test” all of this upgrading is silly. That shouldn’t be a users problem to validate that “upgrade” works. It just should.
Most of the time, I have had very few problems upgrading. But, when they do, I know what to do because I have experience upgrading WP, and understand what to do when something breaks. The average joe doesn’t, and this is where the clear lack of the upgrade system is a real problem.
I know in 2.7 there is now a plugin installer. Yay! It’s about time. I really look forward to that taking the burden off of me yet some more to handle the installation piece.
I may have been obnoxious, but your general attitude makes me feel that you do indeed feel that way.
Dude, if your car breaks down, it is YOUR problem. You either know how to fix it yourself or you hire someone to fix it.
It’s the same argument.
Why do I have to know linux commands to write a blog?
You don’t. You can blog on WordPress.com or you can hire someone to manage your domain.
You’re not getting this. This is like trying to communicate with Helen Keller.
I do get it… but what you and I have is an impasse. You want to just give up on those folks, and I want to help them. That’s the main difference.
I as a WordPress user feel very impressed with the new exciting features they are putting in. Before upgrading you can always take a complete backup of the database and all the files on your host, so that when something breaks, you can restore the older version. The abundant features, being uptodate and closing any security holes immediately makes WordPress the best Blogging script. I would say Go ahead WordPress Go ahead, keep up the good work.
The problem isn’t with update cycles per se, as some updates (security issues) need to be frequent. The problem is with total redesigns of the backend, structural changes that alter the fundamentals behind what make the plugins work. This is especially onerous when such redesigns (like 2.6) basically fix what ain’t broken, add no security improvements, and break a whole bunch of plugins and themes.
The release cycle is FINE. What y’all did with the new release AIN’T.
My advice is, when revolutionary (rather than EVOlutionary) changes are made in the release cycle, that the previous versions should be re-released with all applicable security fixes (in the case of 2.3.3, there were no documented security improvements from switching to the new version) for a period of six months to a year, allowing the plug-in authors time to make fixes and the bloggers time to make adjustments.
Like I said, since there weren’t any documented security fixes from 2.3.3, it’s not applicable in this case, and anyone concerned about plug-in compatibility should have *known*better* than to upgrade before their plug-ins were compatible, or have altered their sites accordingly.
I pretty much agree with your thesis (though I do think that as better “testing” system would probably make it easier for third-party plugin developers to test their code with new releases), but my only problem with this is that it goes against one of the biggest mantras of the community, i.e. that plugins let the platform “do anything.” If you are going to tout the extendability as one of the biggest features of using WordPress over something else, you can’t say that the only plugins guaranteed to work are “official” plugins without speaking out both sides of your mouth.
Ultimately, yes, plugin authors are responsible for testing and making sure that their code works with the latest versions, but I think that WordPress’s lead developers should also work to develop a list of “best practices” or at least a loose plugin framework, to try to better ensure compatibility in the future. Therefore, if your plugin follows x guidelines, you can look at a document to see if anything is changing and assess immediately if your plugin will break or not. On a separate note — I personally think that PHP’s low-barrier to entry results in lots of sub-par plugins littered amongst the well-coded solutions (not saying PodPress is subpar, not at all) and the end user can’t tell between crap and something well done.
It’s great that anyone can contribute to a project and that most of the project is free, but “free” still has a cost and that cost, especially for plugins or add-ons is guaranteed compatibility. It’s hard to fault the developer that gets paid nothing to update his software to work with the latest revision if he doesn’t plan on upgrading himself or if his real job gets in the way. But the “as-is” nature of this sort of development should be better represented to the end-user and not white-washed under the guise of “open source makes all development better/faster.”
So I think that it isn’t just about “not blaming WordPress” but having realistic expectations of an Open Source and “free” project; and the onus is on WordPress to help keep that message on target.
Well said Christina! You have injected some clarity into a lot of jibber-jabber.
I concur. 🙂
Chirstina I agree with you whole-heartedly.
One of the best and most frustrating things about WP can be the plug-ins.
Plug-in authors deserve a lot of credit for the amazing work they do.
But sometimes a plug-in either becomes outdated, or the author moves on or whatever, and the community is not longer able to get newer versions.
Perhaps it would be nice to know those plug-ins that have an active development process, and those that have stagnated, and the plug-in be noted as such?
Make the plug-in author submit something periodically that indicates the developer is still supporting the plug-in?
If you are going to tout the extendability as one of the biggest features of using WordPress over something else, you can’t say that the only plugins guaranteed to work are “official” plugins without speaking out both sides of your mouth.
And WHERE does WordPress state that only Official Plugins (is there such a concept even?) are guaranteed to work? I can’t find that ANYWHERE.
I personally think that PHP’s low-barrier to entry results in lots of sub-par plugins
And also a lot of VERY EXCELLENT plugins. It’s almost as if you are implying that choosing PHP (the most popular web development script) was a mistake, because it’s too easy for just anyone to write a (crappy) plugin.
The WHOLE point, that you are choosing to miss, is that it should be as easy and as straightforward as possible to extend WordPress.
Just before this, you try to make a point that WordPress should make it EASIER for plugin authors to write plugins (that DON’T EVER BREAK) by publishing guidelines and a “loose plugin framework”. Which is exactly what WordPress does do. But which is it? Do you want to make it easier or harder to develop plugins? Please choose.
It is an impossible task for WordPress to ensure that plugins never break. As WordPress progresses, outdated plugins will break. If WordPress tries to be backward compatible with every plugin ever written, you land in the spaghetti code problem of Microsoft Windows.
If you are UNHAPPY about this, you can fork the WordPress code and continue development of the core code to make sure NOTHING ever breaks. Good luck to you on that venture.
But the “as-is” nature of this sort of development should be better represented to the end-user and not white-washed under the guise of “open source makes all development better/faster.”
Have you read the GPL? Please, all this information is in the public domain. Nothing is being white-washed.
the onus is on WordPress to help keep that message on target.
Pure Bull. The ONUS is solely on the user to assess for themselves whether WordPress is right for them.
It should be accepted by anyone choosing to use WordPress and install themes and plugins that whatever they choose to install remains their sole responsibility to make work. There are no warranties.
This software is FREE. If it stops working for you because you upgraded and the upgrade broke your installation, you must have a plan for rolling back to the last working installation.
Jeeze, it’s just software. Relax!
And also a lot of VERY EXCELLENT plugins. It’s almost as if you are implying that choosing PHP (the most popular web development script) was a mistake, because it’s too easy for just anyone to write a (crappy) plugin.
Did I ever say anything derogatory about PHP? Don’t put words in my mouth. But the simple truth is that PHP’s popularity and comparative learning curve make it a very common first language for many programmers. Hence, a lot of PHP coding is done by people that don’t know what they are doing. That doesn’t mean that PHP is bad — far from it — it’s just a reality to being the biggest fish in the sea (and in WordPress’s case, the biggest fish in the biggest school of fish (PHP-based CMS systems)). There was lots of crappy Perl code out there too. As Python gets bigger, there’s bound to be lots and lots of crappy Python code. That’s not an indictment of WordPress, PHP or plugin developers – it’s just a reality that a lot of coal is mixed in with the diamonds
The WHOLE point, that you are choosing to miss, is that it should be as easy and as straightforward as possible to extend WordPress.
I don’t disagree with that — a framework to provide some sort of structure would be nice, even for seasoned developers. That doesn’t mean being backwards compatible with everything — I never even suggested or intimated such a thing (that’s just plain silly, especially for a web app), just a system to maybe make it easier for plugin developers to see if changes made to the structure are going to affect their plugins.
As I see it you, have two reasons plugins fail:
1)There was a major change in a core function (like post revisioning) that the plugin wasn’t designed to handle or understand.
2)The plugin author was hacking around an undefined path (probably without even realizing they were doing it wrong) and cleaned up or optimized code broke their hack.
I would never expect WordPress to fix the second scenario — it’s going to happen, but you can only do so much. The first scenario might be made less severe if it were easier to see what kind of changes are being made without having to pull up git or subversion and compare diffs of every core file. That’s all I’m saying.
If you are UNHAPPY about this, you can fork the WordPress code and continue development of the core code to make sure NOTHING ever breaks. Good luck to you on that venture.
Excuse me? I’m not complaining about how things work now — simply stating my opinion – an opinion you’ve clearly misunderstood or chosen not to read all the way through. Yes, I’m fully aware that using WordPress is my choice. In the situations that are best served by using it, I use it. For other situations, I use Drupal or ExpressionEngine (all PHP based, I might add).
Pure Bull. The ONUS is solely on the user to assess for themselves whether WordPress is right for them.
It should be accepted by anyone choosing to use WordPress and install themes and plugins that whatever they choose to install remains their sole responsibility to make work. There are no warranties.
This software is FREE. If it stops working for you because you upgraded and the upgrade broke your installation, you must have a plan for rolling back to the last working installation.
You know this, I know this — but this message is often white-washed. It isn’t WordPress or Automattic’s fault, and I very much doubt it is intentional — but when you sell something (and free or not, WordPress is “sold” — it’s advertised, it’s promoted — let’s be adults and be honest) as “easy to use” and “powerful” and when an entire industry is being built-around the idea of using WordPress to power a business or an entire site (and again, that’s no one’s “fault”) and WordCamps and PodCamps and websites like this one tout how easy a system is to use, how wonderful the possibilities are and how free it all is, the “as-is” nature DOES get lost in the sales pitch.
I am refuting your idea that PHP is what leads to a lot of crappy plugins being written. Bad programmers are solely responsible for writing bad code. They can choose any programming language they like to write crap code.
There is a system to keep plugin authors up to speed with WP developments. There is a mailing list and there are beta releases, and there are people to approach and information about upcoming releases is regularly blogged about by the WordPress development team.
Are you subscribed to the mailing list? Regular discussions are held there. What else do you want?
There is ONE reason why plugins quit working: the plugin author fails to upgrade it. In this thread, it is stated that the WordPress team actually wrote a patch for the PodPress plugin and the author failed to do anything with it. PodPress stopped working for one reason and one reason only: a lack of interest on the plugin author’s part.
Your first failure scenario is already covered. A plugin author can download beta code, install it and get ALL the information about ALL the changes that have been made, and they can get ALL the help they need from the WordPress development team (and many others) to enable them to update their plugin to work with the new release. They just have to be motivated enough to actually do the above.
but this message is often white-washed.
There you go again. Nothing is white washed. All this information is already in the public domain. Just read the installation instructions and you will understand that WordPress strives to bring the attendant upgrade risks to people’s attention.
but when you sell something as “easy to use” and “powerful”
It is easy to use and powerful.
[…] the “as-is” nature DOES get lost in the sales pitch.
How come I did not miss that? I must be a frikkin’ genius.
LOL!
For once, here we are in agreement.
People can code like crap in just about any language, PHP, ColdFusion, Perl, ASP.NET, whatever. There is no excuse for anyone to bust on the use of PHP. It’s simply the language that is used for WP.
I also agree with your sentiments about broken plugins. They are broken because the author didn’t upgrade them.
But, WP could have a process that allows for those sort of plugins to be flagged. Have the author fill out a form that indicates they are still developing said plugin, or else have it relegated to the “plugin graveyard”. Why have a plugin on WP available for DL that is no longer maintained?
Sure, WordPress could flag a plugin (on their extend/plugins site) that is broken, IF they know about it. But would people bother to check it?
More likely they’ll just go ahead and upgrade their WP and then cry and whine about their system being broken after the fact and blame WordPress for not wrapping them in cottonwool and making all the bad code go away.
Boo hoo.
Well now, at least if a system was in place do deal with it, there really wouldn’t be an excuse.
Hiding our heads in the sand doesn’t solve the problem. It just hides it.
Oh, and in my comment, I suggested a system where WP WOULD know about since the author would have to take an action to indicate that the plugin was being maintained.
What is your issue with the author taking an action to prove they are still involved?
More likely they’ll just go ahead and upgrade their WP and then cry and whine about their system being broken after the fact and blame WordPress for not wrapping them in cottonwool and making all the bad code go away.
Boo hoo.
This comment says a lot about what you think of the WP user community.
Personally, I don’t really have an issue with the constant upgrades, and have to thank the WP team for being so dedicated about constantly improving the code base and adding new functionality (mostly welcome)
I’m inherently lazy when it comes to updating my WordPress installations, so I upgrade maybe once a quarter (unless there’s some major security alert) and as such I tend to have to jump two WP releases as a result, and tend also to wait for the .1s as I’m not a brave beta tester.
Back to plugins: I think the inherent issue here is we (normal human beings) tend to rely on saints (plugin authors) to keep their plugins up-to-date for every new release. I am not a plugin author (I wish!) but I can imagine it being ever so tedious playing the keep-up game, especially if your plugin is very popular (and even more so if it fully utilises all the funky WP inner-working hooks) and if a plugin crucial to a site is not updated, it’s difficult to justify upgrading the core WP installation as well, and most probably don’t. This is an individual’s choice, and as such, the WordPress Team should not have to receive any negative comments from anyone about this (but a gentle prod is probably necessary if the documentation isn’t sufficient)- so yes, I do agree with Jeff’s argument in this regard.
However, I do have a small point to make about 2.6: the introduction of the post-revision function. It’s a great concept, but I was actually dismayed to discover that this is somehow a default thing? I would personally have marked it an opt-in option, but no matter. The main problem I have is: why on earth is this not part of the options in ‘settings’?
I read a ticket on Trac just today asking for it to be added, and the reason given for the answer ‘wontfix’ was because it would over-complicate the settings panel. The only way to turn it off at the moment is to add a line to your config or use one of the new selection of plugins designed for this purpose. I really fail to see the logic here, and it would be great if the WP team could consider adding this extra option.
What’s the issue you have with post-revisions? Why would you want to turn off a feature intended to save you a lot of time in that one instance when you need it?
I’m finding I really don’t need the extra revision versions since I am the only author. I think it’s useful for collaboration projects, but for a single author at the moment, it’s a little OTT.
I know moderators on the forums have said ‘what’s with using a little more space’ but in real life, if you don’t throw/give away things you don’t need, it just ends up being clutter.
So, where did it impact you?
I can understand if the revisions feature was killing WP performance… but other than some poorly written WP core code, how has it affected your blog?
When I first read those threads over at the WP support forums of users complaining about the revision feature, I wondered what all the fuss was about.
The only person who had a legitimate complaint, was a user who posted about some of the queries in the core files, and how slow they had become. This seems like the kind of issue that should’ve been dealt with PRIOR to introduction of the feature in 2.6. But other than that, I can’t imagine what difference the revisions will have in a blog that doesn’t use them.
Actually, I am the sole blogger on several of my blogs. The revision system is actually beneficial for several reasons, but here is a real good reason: If your blog gets hacked, and they manage to screw up a bunch of your postings, you can revert them back to the “clean” version.
I know that’s a dire reason to have that feature, but it’s a good reason nonetheless.
@Robert: I backup my blogs every couple of hours every day automatically (courtesy of the excellent WP DB Manager plugin by GamerZ) and as such, I don’t see myself needing the extra versions of the same posts (I’m not as dedicated as some and only post once every few days) so the backup would mainly be for new comments.
But don’t all the extra versions make the database size larger when I backup my database? If I really have decided I have no need for the extra revisions, then I’m kind of failing to see why I should keep them at all in the first place.
And just to re-emphasise what I had originally asked/said: I appreciate that this feature is a good concept, but what I don’t understand is why this (excellent) feature (for some in particular) can’t be turned on/off easily in the Options/Settings page of the Dashboard. Perhaps I should have made this clearer in my original post.
p/s: About performance, I am no expert on WordPress, so I can’t say if it affects performance or not, and will just have to trust experts when they say it doesn’t. 🙂
Interesting, that you are so worried about your WP install failing, you back it up every couple of hours?! And the revisions feature bothers you?
I understand what you are saying, and yes, the revisions do add to the size of the DB. But, not everything is backed up as part of the revision, if that makes you feel better… 🙂
Well, if you are so against the revisions, do the hack on your wp-config file and call it a day, and never look back. Case dismissed.
Sometimes the core developers have a real tough time, adding functionality, but also having to decide how it should impact the UI. I understand their desire to keep the UI simple, and adding an interface to the “revision history service” or whatever may require some serious ‘splaining.
For what it’s worth, I think that both sides of the argument (who cares about revisions and I don’t need them, can’t I turn them off) both have valid arguments. But, the revision feature is gen 1, and I think will get tweaked as time goes. I imagine that a toggle will come eventually.
For some reason I can’t reply directly to your latest comment, so this will look a little out of place: Yes, I know – call me paranoid about the backups 😉
A little over a year ago, my host had a massive hard drive failure that took out the hosting service for day or two. I used to backup once a week at the point but it meant I was potentially missing out on days of forum and comment posts. Thankfully they were able to restore it all in the end from their backup (so it was only a few hours), but since then, I’ve always been keen to ensure I personally have really up-to-date backups (forum posts and comments since they both share the same database)
Again, I’m not against the feature itself, but as I have no need for it, I have already turned off post revisions by adding the line in config, but I really think a simple on-off would suffice in the admin options (maybe under Miscellaneous? :)) If someone wants to do funky things like ‘only post revision for category x’ or ‘per-post basis’ then a plugin seems to be the way forward.
So I hope as well that a toggle will come eventually, but I’m not very hopeful given the ‘wontfix’ response here: http://trac.wordpress.org/ticket/7360
someone already wrote a plugin to turn revisions off.
http://wordpress.org/extend/pl.....n-control/
In my case, on a single-author blog, I don’t need Post Revision tracking. If I edit a post, it’s to add tags. Add a URL (because I’ll compose, and then add the URL to supporting arguments or links). Fix spelling errors. These aren’t things I would want to roll back. And no one else is going into my system and mucking around with my text. 🙂
So, yes, there are some authors and some blogs for which Post Revisions are pointless. The thing is, there should be some option. Yes, for the vast majority it’s a “Who cares? No one can see these things except for you when you go into your SQL database,” but why clutter up the database with extraneous content when it’s unnecessary? For some people, it’s a good idea. But it’s not an idea for everyone.
So, I followed the directions, turned Post Revisions off in the config file, and then whipped up a plugin to turn all the Revisions into Drafts for later recycling. It’s just how I roll. *shrug*
For the most part I agree with Jeff’s assessment that the testing and updates to a plugin to make it compatible with a version of WordPress needs to fall to the plugin author.
What I take issue with is the frequency of Major releases (2.5=>2.6). Though it’s always great to see new features and enhancements it does make for a more hectic and rigorous plugin testing schedule when these major releases come 3 times each year.
Yes, WordPress security updates and bug fixes need to be released regularly, and I think that the team does a pretty good job of making those available. But I’m not entirely sure that 2.6 was 100% ready when it was released. PodPress problems aside, I’ve seen no end of other little niggling issues with the Admin posting UI. Everything from spotty performance in the “Timed Posts” widget (ie nothing happens when you click it) to the new fancy media bar dialogs not opening as popups and navigating away from the post I’m trying to write.
Lets not get caught up in the trap of “we must release more often to be successful”. When making changes for a Major release of WordPress, it’s critically important to ensure that there’s been enough testing done on the core components, and that takes time. If WordPress goes to a 6 or even 9 month release schedule for major upgrades plugin authors will have more time between these releases to test with Betas and RCs, and each new major version will be a more significant upgrade. 2.5 was huge… 2.6 almost seemed like a maintenance release by comparison.
So lets stop and think clearly about this. It isn’t the WP Dev Team’s job to test for plugin compatibility. But it is their responsibility to maintain the WP core and continue to provide the appropriate resources, including time, for plugin developers to do what they need. Perhaps 3.5 months between major releases isn’t a realistic timeframe. The 2.3->2.5 transition was much smoother, and I’d wager that the 6 month window had something to do with that.
The problem isn’t the updates. The problem is that there is no actual structure to the release cycle. Random updates are often folded in with security fixes. If there are security fixes, then surely they can be rolled into a separate, more regular release cycle?
Instead, a release is often filled with all manner of changes to the core structure. So a plugin that would have worked just fine after a set of security fixes are rolled in, breaks because a dev folded in a change that just happened to be made to some part of the admin interface.
I stopped using WordPress when it became clear developers had no real roadmap – instead, changes are done ad-hoc and often by the seat of the pants. Security updates will seldom break a plugin unless said plugin uses some method patched in the fix. Instead, it’s changes to various core elements that causes the problems.
Plugin compatibility is, really, up to the plugin developer. However, their life is made much harder by the lack of forward planning. Unless they run additional copies of the SVN trunk, they have no hope of knowing whether a scheduled (or short notice) fix will break their code.
This is very much a case of something being made harder, not because it needs to be, but because there is no real clearly defined upgrade methodology. Changes should be planned, not simply telegraphed to the few who still read the SVN commit logs when it hits SVN when the devs decide to add changes.
More frequent updates mean a better chance of improving security – however that doesn’t mean that each release must have all the latest bells and whistles as well.
Upcoming code changes should be slated for release and delivered to a timetable. Whilst that is getting better, it’s far from perfect and that simple change would make life far less taxing for those maintaining wordpress code.
I don’t even understand half of the shit I just read but I read it anyway. Lol
Next they will be asking for a refund… oh wait…
Nice post 🙂 Id like to see more like this
Richard Catto, you are so on the money. I hate to be blunt but, I will anyway, If you do not like the product, GO TO MT. Pay your Premium Price, and then Complain.
100% Correct. From my pov the wordpress team does a excellent job providing information about upcoming releases, and i definetly perfer a good release cycle instead of waiting half a year.
I have no problem with WP or you, or anyone else!
Why would I complain about WP? The best of the best is not good enough for me? (Though I still have a special place in my heart for b2) LOL
There are THOUSANDS of plugins available for WordPress and to expect them to test “the popular ones” prior to releasing new versions is a bit silly. Who makes the list of which ones are popular? Is it up to WordPress to keep track of that, too?
Seriously, if you use specific plugins that are so vital to your site that it can’t run without them, it’s up to you to install wordpress on your own blog on your own hosting account where you have full control. Then, when a new version get released, upload it to a test directory, make sure everything works the way you expect prior to uploading to your live site.
It’s not rocket surgery.
“It’s not rocket surgery”
Hahaha! Great comment.
Absolutely! The WP Dev Team does more than enough considering the software is free in every way.
If a plugin author wants to write a plugin for WP 2.6.1 tomorrow, doesn’t he/she have to first make sure that it works with 2.6.1? The same goes for when WP is upgraded, if the author wants the plugin to still be used, then he/she has a responsibility to upgrade his plugin as well.
Let’s not start knocking the people who provide us with what ultimately comes down to being a gift, a free blogging platform that rivals nearly any other available, free or premium.
I would think the WP team would welcome constructive criticism. You can call it “knocking” if you want but I’ve read some good suggestions above.
The air we breathe is free too but that doesn’t mean people shouldn’t campaign for it to be cleaner.
I generally agree with your sentiments.
However, I do believe the WP team could provide a better system in the core to facilitate the upgrade process.
Perhaps if they provided a system that went through a checklist, it could flag those plug-ins that fail a validation check, and then allow the user the choice of upgrading?
For me, it’s the upgrade process in the first place which causes so much angst. I say fix it, and allow the system to upgrade itself properly.
I have problems with WordPress, and I’ve written about this before. Since I always wait a couple of months to upgrade, I don’t care when they’re released. And I don’t care about this plugin, but I can see why bloggers that do use it – and it’s huge – are annoyed.
I know it’s all volunteer. But whoever writes the PR is really misleading to would-be bloggers. WordPress is powerful, but really really hard to understand. The Codex is almost impossible. It’s NEVER in layman’s terms, NEVER. And I’ve been reading it and turning to it for over a year, and it never helps.
I think people want to help in forums, but as I answered someone asking for help, I think about 10% of all questions are answered at all. Actually, I wrote that optimistically. I would say about 1 out of 30 questions is answered. One of the most frequent responders is so incredibly rude and snotty that I complain publicly there about him/her. You know who I mean. That is unacceptable, that he/she has top member status here.
I get most answers by studying the CSS 3 site and reading those generous bloggers out there who have actually solved a problem, or hacked their own blogs. I am also very very fortunate to have chosen one theme, Mistylook, that has an excellent forum that answers most questions.
I bet the name begins with an “M.” 😉
Blaming the WordPress team because they improve their software, because independent / third-party developers have to keep up and not all of them do, for whichever reason?
My head hurts, just by realizing that apparently there are people out there who think so… Down with initiative! Death to progress!
Ugh.
It’s a bit like recent versions of windows isn’t it. When the core program isn’t compatible with any of the existing peripheral software, users will end up leaving the core behind.
It would be really sad if that happened with WordPress, because it’s generally a pretty good system.
And it isn’t as though WordPress is entirely devoid of blame here.
One simple answer to plugin incompatibility would be for wordpress to cease promoting plugins that do not work with recent versions or are not adequately supported.
I’m thinking of Next Gen Gallery here, which despite a colossal number of unresolved questions and complaints in the WordPress forums (because there is no other support) is still being actively promoted by WordPress.
Anyway, just some thoughts. I’m sticking with word press for now. But I’m a bit disgruntled. 😉
Tru,e Next Gen Gallery does have an awful lot of complaints but that doesn´t mean it´s a bad plug-in – it´s actually an awesome plug-in with a feature set that should be on the top of the list for inclusion into the wp-core (or whatever you want to call it). The support available at Alex Rabes (NGG author) homepage puts a lot of other plug-ins to shame. Just to put this in context NGG is not for dummies as are most other “Useful” wp plugins. Of course the authors are responsible for keeping their plugins compatible and with a release cycle like wp has, that involves time and effort. The same must be said of being a WP user – running a steady installation of wp does require time and effort but it is worth it. If you want hassle free blogging get a Tumblr or blogspot account. If you want to run a powerful blog get WP and host it yourself but don´t blame wp or plugin authors if you as a User aren´t prepared to bring the required time and effort.
Soo true!
I totally agree with you, the WP team gets all the blame, while plug in authors are just lazy with updating. They should be blamed.
Amen!
i keep my plugin use to a minimum because wordpress itself is much more important to me.. though i am sad that my post views seems to have stopped working since i last manually reinstalled 2.61.. but i don’t blame wordpress for that
Can you use one of the available plugins that disable post revisions to make PodPress work?
If that is the only thing keeping PodPress in the dumps…not the point of your post,I know.
People who complain about WordPress forget that it’s excellent and free and therefore above reproach in my mind. WordPress for president?
While in total agreement regarding the central argument – it is not an Automattic task to verify plugins – you have, to a certain degree missed the point of why plugins often fail. Most of the comments are also uninformed.
As mccormicky points out People who complain about WordPress forget that it’s excellent and free. Very true – but so are plugins. And plugin authors do not work full time at their task and do not have a team of people standing by to test everything for them. Most work alone and in isolation and do their best.
As a plugin author, the regularity of WP releases do not cause me any problem. The real problems, especially over the last 4 or 5 releases, is the way the WP team discard components and introduce replacements in a very cavalier way. And these changes often break a plugin.
This is bad enough but more often than not these changes arrive largely unannounced (unless you download development systems regularly which many authors do not have the time for). Often, the first you hear about them is a blog post (written sometimes by a WP developer but just as likely by an avid fan) which gets published at the same time as the new version is released. By which time your plugin has broken.
The level and quality of documentation available – especially for new features and changed functionality is, to be frank, often non-existant or scant at best. I have long argued that WP has such a dominant and popular position largely because of plugins and themes. Yet very little help and attention is given to the very people that create these valued extras. A little more time and effort spent educating and assisting plugin authors – especially on the curse of changed functionality – would go a long way to eradicating breakage and would serve to heighten the WP reputation.
Finally – by way of example – there are places in my code where I have to perform the same task three, sometimes four different ways if I wish to continue to support uses on older WP systems. And by older, I only mean 2.2. And 2.7 – now in development – has already broken my plugins.
Fortunately, I DO have the time to track most WP changes in the pipeline but please spare a thought for all of those who don’t and then end up taking unnecessary abuse from their users.
Well said.
Lots of comments like Blaming the WordPress team because they improve their software – totally off base. Totally.
Security fixes are unarguably improvements.
Changing functionality? That may, or may not, be an improvement. That is a subjective user decision.
Changing functionality in such a way that many popular 3rd-party apps are rendered useless? I would think that users of said apps would NOT call that an improvement to the software. I like using WordPress, but let’s get off the rah-rah blind cheerleading, shall we?
The WP press releases – upgrade NOW or GET HACKED! – are also all wet, esp. when the major release doesn’t include any security changes from a secure prior version. The obvious answer is security releases supporting all major branches of prior versions for long enough to give plug-in authors time for fixes, and blog authors time for changes.
On the other hand, users should be savvy enough to know NOT to upgrade until reading 3rd-party reviews, esp. if they use any tweaks. They should also be savvy enough to upgrade reversibly.
On the other hand, users should be savvy enough to know NOT to upgrade until reading 3rd-party reviews, esp. if they use any tweaks. They should also be savvy enough to upgrade reversibly.
Not sure I agree there. There are many users who have WP blogs, but are by no means “savvy”. They just want to blog. Sometimes, they use the free WP install that came with whatever hosting plan their provider game them. Other times, somebody else has been handling the upgrade chores, and then leaves.
Operating a WP blog SHOULDN’T REQUIRE a savvy user. It’s such a user friendly system, that to throw in the term “savvy user” implies that only people who know PHP and understand Linux permissions should be operating a WP blog. And those “savvy” users don’t make up the majority of WP users, I would guess.
Saying that the user should know not to upgrade is silly. How would they learn that? A user who just got his blog, and his host gives him a 2.3 install to go from wouldn’t know anything about that. He’s just a simple user, who wants to blog.
Perhaps this is an area where the WP team can help users out by making sure the blog itself handles the upgrade process, and tests for certain compatibility features before allowing an upgrade? Or leaving it up to the user to accept if certain plug-in’s fail?
I think there is room here for improvement. I don’t think the plug-in authors are off the hook, but I definitely think the WP upgrade process needs work.
By “savvy” I don’t mean “capable PHP coder and erstwhile Linux command-line hacker” – I mean someone who has a basic understanding of the ins and outs of software upgrade cycles. That’s all.
Your case of the simple user is most likely moot – as they wouldn’t be the type that installed plugins to begin with, so they wouldn’t have the issues or concerns that I’m describing.
People need to understand the differences between security fixes and so-called “product enhancements,” and use that knowledge to determine whether the “upgrade” really IS an upgrade, or whether it’s just new bells and whistles and that might, or might not, be an improvement, depending on the number of structural changes. Someone who’s savvy enough to handle an install of WP and a few plugins, and who’s lived through a couple of “upgrade cycles” of different software packages (MS Office, Windows, Thunderbird, Firefox, etc.) should KNOW THIS. Whether or not they code (for the record, I hack, not code).
“How would they learn that?” you ask? From LIFE. From simple experience with other software cycles and their own laptops or home PCs, transferred from that realm into this realm. It’s a thought process that defines “savvy,” not the ability to write code.
Fair enough. However, I believe the real issue, isn’t even these kind of folks, these “savvy users”. And I still don’t agree regarding your definition of a “savvy user”. As savvy and smart as my wife is, she has no idea whatsoever about versions of software, nor does she care. That’s my job to know. She simply wants to blog. And I don’t know what normal users deal with “software cycles”, but I imagine that’s a tiny group, in comparison to the whole. I know that I don’t upgrade unless I need to. I upgraded from FF 2 to FF 3. But a dot release, unless it’s a security fix that is mandatory, I will usually eschew. There really isn’t any “cycle” in the real world. There are so many products, released at so many times, what kind of cycle is there?
How about the thousands of older WP installs still going strong? How about the thousands of the hacked 2.3 installs all over the place? These users aren’t aware of the hack. It’s invisible to them. They don’t upgrade their blog because, they don’t know they NEED to.
WP is great if you are plugged into the system, and aware of what happens.
But, where it broke down, was the where it let users off the hook of NEEDING to be aware of what was going on.
I do like the new features that provide tons of visual feedback about what needs to be upgraded, and when a new version is out.
But, the WP team needs to make upgrading a more transparent process. WP needs to upgrade itself, and let the user KNOW when it’s time for an upgrade.
Incidentally, I don’t believe that an average user would care to suffer through botched upgrade after botched upgrade just to be a “savvy user”. I get it all the time when I first show my users how to use the One-Click plug-in installer (a feature I believe ought to be built into WP, IMHO), and they start installing plugins and themes, and they screw up their layout or something wacky like that.
But, after a while they get the hang of it, and learn what’s REALLY effed up, and what we can fix. THAT is the kind of experience I expect. But, I wouldn’t want most users to do that. That’s why, IMHO, WP needs to enhance the upgrade process.
Not everyone has the time to spend “administrating” their blog. It’s supposed to be easy. It doesn’t need to be a pain.
People need to understand the differences between security fixes and so-called “product enhancements,” and use that knowledge to determine whether the “upgrade” really IS an upgrade, or whether it’s just new bells and whistles and that might, or might not, be an improvement, depending on the number of structural changes.
Wow, that’s a mouthful.
When WP issues an update or a new version, it’s just that, a new version. Sometimes, they say it’s an emergency “must-upgrade” security fix.
But, when they went from 2.5 to 2.6… well now, that’s a full dot release, and that means a whole lot of things. Security patches, new and improved features, etc. What would compel a user NOT to want to upgrade?
For me, it was the plug-ins. I wasn’t sure which ones were upgraded yet. Some, like the NextGen Gallery, where the developer actively maintains it, had already done the homework, and had released a version semi-compatible. But others weren’t, and I am still waiting for them to be updated.
In all, I don’t believe you can make all users “savvy”. But, if we can take a middle ground, to help those users out, it makes it easier on us “real savvy” users to administrate our users blogs, and make WP even MORE successful.
I have no regrets switching from TypePad to WordPress but there is a steep learning curve for us non-technical bloggers. That being said, common sense and a precautionary approach to things works best in my opinion. I am currently at version 2.5.1 of WP and 8.8 of Podpress and everything just works so I am hesitatnt on changing/updating anything at this point. I am just too worried about breaking some functionality and then not knowing how to roll back to when the site was working properly.
As to the issue of the Codex being complicated for non-developers I would have to agree but at the same time doing a Google search on any problems that I have run into seems to work well. I have been wondering how I may in fact be able to contribute to wordpress development. Maybe I can help out with a “Non-Geek” Codex or something along those lines.
What is the learning curve you are talking about?
MT has a much steeper learning curve. If you don’t know Perl, then there’s that hurdle to jump. Then, where do I put my theme files? Oh, depends on the theme… etc.
Without any real mods, WP is much easier to use for most people.
As far as the Codex, it’s for developers. I don’t think you can read through it and understand much, if you don’t have a passing understanding of PHP. You don’t have to be a developer, but you do need to know something about programming.
If you think WP requires a steep learning curve… try customizing a MT install!
Maybe I’m biased because I work in the IT industry, but I disagree about the Codex. Yes, some of it is very esoteric, but much of it isn’t any worse than most Windows software manuals that I’ve read.
However, I totally agree with you about trying to customize MovableType. I used MT for a couple years and knew Perl well enough, but it was still almost impossible to get any level of usable customization on my MT install. WordPress, on the other hand, was a dream! Between plugins, and working out my own code from the Codex and searches for PHP code via Google, I was able to do things in just a couple days that took weeks, months or eternity in MT. It was the difference between night and day!
The real problem here, I think, is that people upgrade without testing. There are several resources for how to install a local version of WordPress for testing. I’ve done it more than once and it’s not that hard. Certainly no harder than setting up WordPress on a webhost from scratch.
Also, it’s important not to think that running your a personally installed copy of WordPress is the same as setting up a blog on WordPress.com. Just like having a TypePad blog is not the same as running a personally installed copy of MovableType. I think that gets confused a lot.
I too work in the IT industry. I am a developer by trade, and host my own Linux based sites, including, but not limited to, WP and MT.
I installed MT just to see what it was all about… I think that blog still says, “I just finished installing Movable Type 4!”
As far as running your own copy of WP, using a LAMP install, it’s easy. How many people will read this thread, and say, “what the heck is a LAMP install? Just tell me how to upgrade.”
I think there is really a disconnect between the “savvy” WP users, and the rest of the WP users. I really think most people who use WP don’t know PHP from a hole in the head. And why should they? It’s not supposed to be THAT hard.
As far as a NON-GEEK Codex, I would be more than happy to try and help you set something like that up.
I complained about Codex above, but I have thought that I might volunteer to help read/explain things better there myself, for others. I always come back and list my solution, very carefully, to help others.
To the commenters who say you need to be savvy for Codex, and it has a steep learning curve, so true. But I have to go beyond that and say it is horribly written, really really bad for people who are non-developers – which means, like, 95% of WP users?
I care about the theme and design, and little things and plugins to add, so I do hack and try things, come back for more, and have probably hacked at 20 themes before I came up with 2 for my blogs. But it took me weeks. And I’m “savvy”, but I don’t know php, or know what all those ? and other symbols mean.
It would be so easy to make it blogger-friendly. But I’m not sure anyone wants it to be, if it’s really written for developers…
Anyway, put my hat in the ring to help.
Donna, it’s unfortunate, but if the CODEX is FOR developers, perhaps it’s not because it’s horribly written that makes it hard to read or understand in the first place? I mean, if you really want to understand it, you need to learn PHP. Go out and get a PHP book, like “PHP for Dummies” or the “PHP in a nutshell” books. Both give a great foundation for stepping into theme or plugin development with WP.
There are a ton of things one must know to use the CODEX. I wouldn’t recommend trying to use it, unless you have the time and patience to set aside for it. And that takes a commitment.
Okay, let me clarify that, Robert.
It’s horribly written for anyone besides developers. I can’t imagine all those thousands(?) of pages, trying to help, were written only for developers, and not at all for us eager bloggers.
Anyway, I’m not interested in being a developer or one of those talented theme designers, but it’s exciting to figure something out to make your blog do what you want it to do.
I would like to help other people do that. Certainly the forums help very little. I know how anxious and excited people are about blogging. I wonder how many give up WP in frustration. We will NEVER know that.
I’m self-taught in this strange world, so I think I could say exactly what Codex needs to do to become helpful to regular bloggers. It’s not that much, really, just some tweaking. Coders just don’t understand it from a user’s point of view.
maybe WordPress should inform some plugin authors about the potential issue, probably a handful of authors, give them the final release 3 days ahead before releasing it to the public.
Everyone has access to the SVN to checkout whatever is brewing.
Maybe plug-in authors should take their job more seriously, and aim to insure that all their hardwork isn’t for naught?
I have hesitated making an official plug-in for a few reasons; mainly because of the headache of providing functionality that may be obsolete or incompatible in the next version, but also because I wouldn’t want to make a plug-in that I didn’t have the time to support.
I agree with you,too!the wordpress team updates the new version which is an exciting thing! The plugins is not Compatible up to new one ,this is due to their lazy!
For anyone who was curious about the future release schedule… http://wordpress.org/about/roadmap/
2.7 November 10, 2008
2.8 February 2, 2009
2.9 May 11, 2009
3.0 August 3, 2009
After reading about 2.7’s new features, I cannot wait for it. It’s got a bunch of stuff built in that i’ve been using plugins for.
Hats off to Jeff for sparking this thread. I do not pretend to be a programer, nor do I pretend to be an authority, but WordPress is Open Source. The whole point of open Source is that if you like what you see, and want to improve it, do it yourself. What I see happening, not just with WordPress but other projects as well, is that people forget that WordPress is just a core. Look how many people use WordPress as a CMS, even though the project was never intended for such a use. Look how many different uses have been found for this project, just because it is so flexible. Where do plug in authors get off thinking that they have ownership of the project? Yes, we all want to feel like our opinion matters. Yes, we all feel that our issues are most important. And I am forever grateful that Automatic has such an open approach to developing “THEIR” product for us to use for free. But it is their product, not ours. Anyone who has worked with third party providers for products knows that at any moment a third party software can be rendered useless if the program they are built on is changed. ACT in notorious for doing this to their third party affiliates. WordPress plugin writers should feel grateful and lucky that they are part of a community where their desires and opinions are heard, and think twice before railing about how unfair it is that WordPress releases so often with out testing their particular plugin for compatibility.
You give a finger and they want the whole hand.
I think the problem isn’t that Plug-in authors want/have too much power.
WP is a great product. But it’s not perfect.
Let’s get real here. Who really wants a vanilla WP blog, with the default theme and no plug-ins (except Askimet, since it’s built-in)?
That’s just boring.
It’s the plug-ins that add that extra “oomph” to WP, and put it at the top of the FOSS list of blogs.
Yes it’s open-source. But, how many forks of WP have you seen? I haven’t seen any… (not that I have looked). Sometimes, forks are not a good thing.
Having a plug-in architecture is PART of WP, and it’s the reason it’s so popular. The fact that they have a standardized API makes it easy to extend, and use for a multitude of non-blog type purposes.
If the WP core team chose to one day “chop off the hand that feeds it”, it would simply become MT. And who wants that?
I want WP to only get better, to get bigger, to show the big guys the RIGHT way to do it. But, that doesn’t mean the folks over at Automattic get a pass. They should listen to their user community. Where would WP be without all the great plug-ins and themes THE COMMUNITY made for WP?
I’ve seen one, it begins with ‘H’. Still in development though 🙂
I run a podcasting site using WordPress and PodPress, so the 2.6 upgrade breaking PodPress does affect me. That said, I understand that I’ve paid for neither bit of software (nor, in fact, the OS and utilities on which they run) and I can’t expect tightly coordinated releases. I’m happy with the short-term workaround posted for PodPress and with the ability to roll back posts in WP.
I’m strictly an end user of WordPress but I’ve been a software user for many decades and know the dangers of upgrading too soon. One of my biggest complaints is the fact that WordPress almost seems to SCREAM at the end user to “UPDATE NOW” whenever a new release comes out. There are dashboard messages, etc. that would make any casual user ASSUME that because upgrading has been “blessed” by the WP team that everything will be A-OKAY.
I’ve noticed the new feature that alerts you when a plug-in has a new update. I was wondering if it would it be difficult to create a feature that also checked to see if the plug-in is verified to work on the newest version of WP? I envision the ability to look at my plug-in dashboard and see, for example, that 3 of my current plug-ins are not tested for the latest version of WP. At the very lease I’d like to see a “compatible to version x.x” similar to what you see on the WordPress.org web site.
I’d suggest that by default all plug-ins are flagged as “uncertified” when a new version of WP is sent out and that it would be up to the plug-in author to update the status of the certification.
It would be really nice if right below that “Upgrade Now” button on the dashboard there was another line that says “3 of your 7 plug-ins are not currently compatible with the new version. Click here for details” and then show me the plug-in page so I can review which are and are not compatible. 2 or 3 weeks after a release — when all of my plug-ins are now “certified” compatible…the message could change and and say “CONGRATULATIONS all of your plug-ins are compatible…upgrade now!”
This would probably slow down the adoption rate of new versions of WP — but I don’t think that’s a bad thing. I wish EVERYONE was smart enough to check things out before upgrading…but many users just assume everything is safe. This kind of system would help to insure that people don’t simply click the upgrade button and then head to their favorite blog to bitch about things when it breaks their system.
In some cases, the upgrades are dependent on the new version of the blog… for example, I had several plug-ins that were updated to support 2.6, but wouldn’t work properly until you had 2.6.
I honestly can’t believe the comments I’ve read above. Limiting major updates to once or twice a year, all on account of keeping WP compatible with existing plug-ins? Eh, what?
I’m sorry, but that is completely ignorant of the point being made here. We are lucky that WP is updated so often, and it would sadden me greatly to see the team stop updating as frequently just so plug-ins aren’t broken.
When you make a plug-in for popular software, you have to accept the responsibility for being on top of updates. Release candidates for the software are put out before the final update; those are for you to use to test a new version of your plug-in for compatibility. If you wait until the final release and then find your plug-in isn’t working, it’s your fault, and not the WP team’s fault, or any of your users.
Say you buy find that the cup-holders in your car don’t fit those “big gulp” cups exactly right, so you go out and buy a small insert, created by a third party, that makes it fit nice and snug. Now imagine that your car’s manufacturer creates a new car, an upgraded version of your old car – even with a whole year’s time in between model releases, the manufacturer isn’t going to check to make sure your cupholder insert works with the previous model. That’s not their job.
The same goes for WordPress and its multitude of plug-ins. We have the benefit of a new release every few months, and I love having new features to play with many times a year. It beats waiting years to get the features we want, and if it breaks a few plug-ins, so be it. The people who make the plug-ins will deal with it or I will find an alternative to them.
Eventually, updates will slow down anyway… but for now WordPress is getting a lot of much-needed additions at a rapid pace, and I like it that way. Anyone who complains about plug-in problems should direct their words at the people who make the plug-ins, and not the WordPress team.
My 2 cents:
If upgrading breaks a plugin, then either one of two things has occurred:
a) The plugin was using something that changed in a major way, or was reworked to change entirely.
b) The plugin was written incorrectly in the first place.
Now, a large percentage of the time, the problem is of type A. In the case of PodPress, revisions broke it because PodPress made the assumption that the post being saved would have a different ID number than it was getting. No biggie, there’s a simple patch for it that works, so people can patch the PodPress code and be on their way. It would be nice if he’d get a rushed out 8.8.1 release or something, but hey, his plugin, his release schedule. I’m awfully surprised that nobody’s forked the code yet though.
However, a not-insignificant amount of problems are of type B as well. This is the result of fly-by-night plugin authors. Somebody makes a plugin for their use, releases it, then never updates it ever again. I too have been guilty of this, and several old posts of mine have broken plugins in them that I never have bothered to update. The only ones I really care about are those I’ve bothered to put into WP’s Extend directory.
But if a plugin author really wants to keep up with what’s going on and what’s changing, then they need to join the WordPress mailing lists. Seriously, if you don’t read the lists, you won’t have any clue about the current state of WordPress, and you won’t see the problems coming up.
The best way to be a WordPress plugin developer is to also be a WordPress developer.
You make some good points, Mr Chandler. However, one little thing that might have made it a little easier for plugin authors to ready themselves would be for the development team to have actually posted on the official blog about the 2.6 Release Candidate.
Well said, Jeff.
Out of curiosity, I installed the nightly build of WP 2.7 (Hemmorage) in my sandbox this morning and installed a vanilla PodPress 8.8. Lo and behold, PodPress works — mostly. There is still a problem with IE unless I install that little patch for the Post Revisions. But it works out of the box with FireFox, Opera, and Safari.
I am always of the opinion that if a plug in is SO popular that most people use it that it will eventually become part of the core product. That’s how most products work.
If your blog relies on certain plug ins then it is your responsibility to make sure the plugins work before you upgrade. This happens all over the industry with software – including OS and infrasturcture upgrades (such as Windows and Apple versions and name upgrades).
You can’t test everything or wait for unrelated thrid parties to be ready to release a product. If you try you end up waiting for ever.
Head Ranter (www.bigtimerant.com)
The bigger problem is plugin security – there’s no one vetting these things and it’s every man for himself. I recently had a plugin seriously muck up my DB. I didn’t know it even had rights to write my my db…
A WP plugin has the same rights to your DB as the WordPress core code.
Exactly. And that’s a prob. Anyone can slap a plugin up on the WordPress site and no ones vetting the security or stability of an app. I’m surprised we haven’t seen some really malicious stuff show up yet… And I know I’m being more cautious with what I use (and what I disclose I use).
Well sure, a malicious plugin could be written to interrogate your database and send a complete copy of it to the plugin’s author. A plugin could also send your db username and password to an unauthorised third party.
But if a plugin did not have full access rights, then the backup plugin would not work, neither would a whole bunch of other very useful plugins.
WordPress could, theoretically, build a whole security system where you would have to grant plugins rights to various parts of your system, but I’m not sure how that would prevent a malicious trogan plugin being deployed.
It hasn’t happened yet, to my knowledge, and if it did, news about it would quickly spread.
Before you install a plugin, you could inspect its code to see whether its doing anything untoward, but I don’t think people are bothering to do that at the moment.
If it became an issue, the WordPress community would have to formulate a response, just like the blogging community found a way to handle comment and trackback spam.
This is the reason why WordPress.com does not allow users to install their own plugins, because if they allowed that, then anyone with a WordPress.com blog could upload a plugin that does pretty much anything they liked.
I see this comment often, and really for the life of me don’t understand how anyone can say it seriously.
Before you install a plugin, you could inspect its code to see whether its doing anything untoward[…]
Are you serious? Now, not only are we expected to be server admins, we have to know PHP too?
Have you SEEN some of these plugins? It’s not that easy. There are a billion subtle ways to hide a hijack into a single line that even a 4 year PHP guy won’t see.
It’s as much an art as anything.
Stop putting the onus on the poor shlep who just wants to blog.
I do admit that normally, you are right in that the WP community would be on to a malicious script. But it wouldn’t be quick enough to prevent the damage.
Not sure I know how to resolve that though, other than if we had a wrapper or test unit that could investigate a plugin prior to installation.
But again, the many ways to hide the code would make any system unfeasible.
Are you serious? Now, not only are we expected to be server admins, we have to know PHP too?
Is it your web site? If yes, then YES!
What don’t you understand about taking FULL RESPONSIBILITY for your own domain?
Anything that happens on your domain is your problem. You are the one who is going to be inconvenienced if you install malicious code.
Even if you download a plugin from wordpress.org, you agree to waive all claims against WordPress should you install something which screws up your domain and costs you money.
Forget your nonsense about “just wanting to blog”. This is Open Source Software. Install it at your own risk.
Please understand that now. I think you have never fully thought this through.
Oy. Your attitude does get old after a while.
I am not in any way saying that I am not responsible for what happens on my blog.
But, you do take it a little too far with your militant approach to what I should have to know to use WP.
They certainly don’t pass that sort of warning along anywhere on their site.
Open source hasn’t got crap to do with it. I use software all the time that I have no idea if it’s got a trojan installed in it or not. We all cannot be developers that have GCC loaded, to actually compile the binaries ourselves.
Did you compile your broweser? If you use FF you could’ve.
Not everything that happens on MY domain is MY fault. So I loaded (at the time) WP 2.3, and then decided to hold off on any upgrades, because I was worried about losing stuff. Well then I got hacked by that wonderful XSS feed hack. Great. How am I supposed to do anything about a vulnerability in WP?
Oh, I suppose I am supposed to know PHP, and have gone over every line of code?
They certainly don’t pass that sort of warning along anywhere on their site.
They do. You just have never bothered to read and comprehend the GPL.
Use Open Source Software at your own risk.
Got hacked by XSS exploits? Not WordPress’ problem, it’s YOUR problem.
What don’t you understand about “as is”?
No doubt there are new problems that will strike WordPress in future, and that means you need to insulate yourself from them.
You’re not helping anyone when you molly coddle them and tell them, “there there, it’s not your fault, daddy is here to make things all better.”
I suppose it’s better just to hang them. There, that fixes the problem.
The GPL and the as-is crap has nothing to do with the discussion.
Are you trying to say, if you don’t like FOSS, then leave?
What kind of attitude is that? How could the software EVER be better, if we didn’t bring our issues, wants, and improvements to those who can implement them?
An improved upgrade system for the blog and the plugins/themes I think would solve a ton of problems.
And I never once suggested that a hack on my blog in any way is WP’s fault (although, they did write the software). The issue is one of the “necessity” for upgrading. I was showing how we get bit by NOT upgrading, so the system is really setup to force the user to upgrade at some point.
What exactly is your solution to all of this? I have only heard you deride those that are mere mortals and say they don’t deserve a blog in the first place.
What exactly is your solution to all of this?
There is no SOLUTION. There is just an APPROACH to adopt.
Honestly, I don’t think you’re smart enough to understand my message or you would have got it by now. I write in plain English, but you still can’t comprehend it. You continually churn out false understandings. So, I have to conclude that you are not bright, which is unusual for a developer. Most developers I know are really intelligent and quick to catch on.
I really don’t care if you think blogging ought to be simple. Fact is, hardly anything in life is simple until you’ve done it so many times it’s become second nature.
Even if you blog on a third party hosted platform like WordPress.com there’s still a million things to learn and none of it comes naturally to anyone. We have to learn how to do things. That is what uniquely distinguishes human beings from most animals. Animals can learn a fairly limited repertoire of survival tricks, whereas human beings have an unlimited potential to learn, IF WE ARE WILLING.
And if you self host WordPress on your own domain, there are a whole new set of things you need to learn in order to effectively maintain your installation.
No-one just blogs.
There are things to be done besides “just blogging”.
Anyone owning a domain has the sole and full ultimate responsibility for what goes down on that domain.
Yeah, they can just install a bit of software without checking it out, and if it works, great. But if it manages to crash their server or become an open relay or join a bot net, then they receive the consequences of installing bad code.
I don’t care how much you wanna fight this and protest it. You can speak to my damn hand from now on. I am done talking to you.
So be it. Talk about personal attacks. Jeeze.
You say there is no solution. I disagree.
You try to point out that self-hosting makes you responsible. Duh! I never said it didn’t. But simply because I self-host doesn’t mean I should compile all of my binaries, blah blah blah.
All I have ever said, and will continue to say, is that the system we WERE talking about, WP, needs to help users with the upgrade process. I am not saying that if your site gets hacked, it’s not your fault. Sure, I could have just NOT loaded WP in the first place. But, then again, why would I want to do that? This isn’t about THOSE kind of choices, so give it a rest.
You are such a black and white guy. For you it’s simple: either accept that using this software could be detrimental to you, or don’t use it. Well, that’s a great attitude, but doesn’t help WP at all. Somewhere, there’s got to be a pipeline of new ideas, of things that need to change because the people who ARE using WP want them to, and the people who MAKE it, want it to be used. It’s a win-win.
I am trying to suggest an improvement that will help plug-in users, and WP users.
You are just adding noise.
Talk to the hand, whatever.
Yo, braniac, I just thought in light of your ignorance of what WP says on their homepage, blogging IS supposed to be simple:
Ok, that didn’t post as I thought it would…
What I meant to say, was that WP says this about their platform:
WordPress is a state-of-the-art publishing platform with a focus on aesthetics, web standards, and usability. WordPress is both free and priceless at the same time.
Seems like all I have been talking about is the usability that they pride themselves on.
Robert,
You seem to not understand the fundamental difference between running a blog and running your own website.
If you want to run a blog, then you should not be installing WordPress at all. You should use a blogging solution, like Blogger, or even better, WordPress.com. These let you blog WITHOUT installing any software, running any plugins, doing any maintenance, etc. Those are for the non-technical user who knows nothing about programming or coding.
But if you are going to run a website, then that’s a different kettle of fish. In that case, you need to know the skills of a webmaster. You should understand htaccess files, rewrite rules, some PHP coding skills, HTML, CSS, maybe even a bit of Perl and regular expressions. These are required skills for a webmaster, and if you’re running your own website on your own hosting, then yes, you do need to know them.
Sorry to disillusion you, but nothing in life is “easy”. If you want things to be easy, then you get somebody else to do the hard work for you. That’s why we have solutions like WordPress.com, where you can host your blog, for free, without any real hassles or knowledge required.
I dunno… maybe I’m being shortsighted, but it kind of seems like much ado about nothing.
There are hundreds of plugins out there – many of them redundant. And there are at least 10 new plugins developed every day. Many of them are redundant, also. So if a WP upgrade happens to break a plugin’s functionality, there’s always another one I can find to replace it on any one of the 24 WP sites I maintain. Bit of a ocassional headache? Yes, it is. But I’m also learning a lot about WP and PHP in general along the way. And I’ve also found quite a few plugins that seem to be overlooked by the general community.
@Carson
Air is a necessity of life, not a blogging tool, big difference there.
And good suggestions are great, but why would anyone take them as anything more than suggestions? The Dev Team does enough work of their own without adding the work of a plugin author to it.
@Robert
That may be something that I could stand behind, like a quick validator for plugins to see if it is compatible with the newest release of WP. It should be a quick code project to make it, and the team would know best which things to include in it that have changed in the new version.
Not saying it should be able to fix the plugin, but it could assist plugin authors in quickly identifying the parts of their plugin that need to be modified, once the validator says “Hey, this part won’t work.”
Right, just something, a test harness or wrapper or something, that WP can use to validate a plug-in works with the new version.
gestroud, what plugins do you feel are overlooked by the general community? While somewhat OT from the point of the post, it may not be overall.
I agree with you, gestroud, that many plugins had at least one copycat or redundant plugin that could replace it.
Sadly, many plugins, as others have pointed out, are poorly written, but there are others that are terrific. I manage over a dozen sites, for myself, as well as for a variety of organizations, and I’ve helped more than 150 people get started blogging by first, giving the new folks blog space on one of my domains — using an install package I have put together, using the WP core, along with 11 different plugins pre-installed, as well as a fair variety of themes. When these people decide they are going to continue blogging, I help them set up their own site or domain, get things moved over (IF they need the help), but stress to them one major thing: TEST, TEST, TEST.
I have several sandboxes for testing things. One just for testing new WP releases with plugins I use; one for testing new WP releases with plugins I use, as well as others I am interested in using; and one for the new WP releases with plugins I use with all custom code to the code, with all plugins I use, as well as other plugins I may use at some point. No plugin goes live on any of the sites I oversee without having first passed testing.
I’ve seen some plugins — handy ones, at that — that I loved, but for whatever reason, they were lacking. In fact, one is a plugin that is a “Tell-A-Friend” plugin, which allows visitors to send an email to others from the page. That plugin, however, conflicted with another plugin from the same developer when cForms was also installed. After talking with the developer of cForms about the problem, he created a tell-a-friend feature for cForms, which he had me alpha- and beta-test for him on my sites. It was all handled within several hours, and he released a new version of cForms the next day. That’s what I call commitment, but also a person who strives for excellence.
I just wanted to add @those commenters who chide, “Well, WordPress is free, so…”
You sound like wide-eyed newbies with their first computer who say, “Wow, the internet is free!”
Uh huh, Woodstock lives.
@Donna Bartow:
The internet is free? Wow! I pay an arm and a leg every month for the internet. Guess I live in the Dark Ages, huh? 😉
Please, no! Once was more than enough. Same with the Hippies and Yippies of the 60s and 70s.
Let me just say, I’ve been blogging using the WP platform for about five years, now, and it’s awesome! Additionally, the WP team are a great bunch of people whose hearts are in the right place. I mean, who else would endure this kind of abuse and still continue put out a quality platform at no cost to you, the user.
Would it be nice if WP retrofitted their platform for all the most popular plugins? Sure. But that isn’t the world we live in is it? Wake up! The WP team offers their time, talent, blood, sweat, and support…all without pay. It’s a labor of love, and a damn good one at that. Plus, (Did I say this already?) you get the benefit of all this FOR FREE. It costs YOU nothing, nada, zilch…you get that? And all I hear is, “Why can’t WP walk on water?” “Why can’t they make the platform work with, with…uh, everything, including the kitchen sink?”
I say quit bitching and give these guys and gals some love. And while you’re at it, why don’t you donate? Maybe if you’d send a check, or a substantive software contribution, you could be a part of the solution to improving WP. That would be in contradistinction to what I’ve been hearing around the WP water cooler lately. To wit, somebody said: “If you’re not a part of the solution, you’re a part of the problem…” and if you’re in the latter category, you need to sit down, shut up, quit using WP, and then go pay hundreds or even thousands of dollars for your next CMS platform.
So please, for the love of God, quit whining; grow up; get real, and be thankful for what you have in WP.
WordPress Rocks! End of story.
During the process of the upgrades to wordpress the trunk does become unstable, but wordpress has a new admin with some slight issues with the new menus but is quite stable at the moment. I would feel safe in many people testing the current revision even on a live site. Testing thoughout the cycle is often good in finding bugs. One might want to join the wp-hackers list first before constantly upgrading trunk do hind out when it is broken.
Trunk Revision 8732
“You snooze, you lose.” Podpress has gone months without any obvious changes although I understand a major rewrite is going on. Still, if WP were to hinge their updates on the ‘flavor/plugin of the month’, they would be in the dark ages because that would encourage complacency. I love(d) Podpress, but had to choose to upgrade & work around it.
I love frequent releases. Just shows how active the dev team is. As for updates, only update id there’s a security fix if you are so concerned about compatibility.
O ya, have those who blame ever heard of “backups”? Do a full backup of your files and DB. Something breaks just roll back…
And can’t they setup a sandbox to test?
Poeple just love to complain…
I’ve only switched over to WP in recent months, and am very impressed with the flexibility and support there is available. The only thing is that there are many versions of plugins that achieve the same (or similar) functions. However, these are also to be appreciated, as these people offered their time and expertise to contribute something back into the community. I really appreciate what the WordPress team has provided the community with, and I think we all should be grateful that we have such a wonderful blog software to use 🙂
The update cycle is too darn quick. There should be a WordPress XX LTS (Long Term Support) or something.
Meh. Don’t update unless there’s a security problem. You don’t have to update right away, you know.
Of course, I say that while I’ve currently got an FTP running and uploading the latest trunk to my own site, so to each his own, eh? 😉
I agree whole-heartedly with the OP. It’s up to the plugin authors to ensure their plugins keep working with new versions.
With that said, the core developers do an amazing amount of work to ensure that backwards compatibility is maintained whenever possible and they document any changes that could break stuff. For example, work is going on this very moment to ensure that the API still works for adding menus to the admin area in the new 2.7 design.
@Robert: I told you to stop talking to me, you ridiculous Neanderthal, so BUGGER OFF!
Ok, I will stop talking to you.
I think he’s saying that because you made a point he can’t possibly argue against, Robert. You are right – wordpress does not say “You need to know this, this, that and the other in order to use our software”. They say – our software is easy and simple to use. Download it now! And then people wonder why users turn up in the support forum asking for help.
I just did an install for someone who had made the mistake of upgrading to 2.6.1 – when I imported their blog, WordPress created over 7,000 unnecessary entries in the database.
I used to be supportive of WordPress and encourage others to use it but after running two test blogs for myself (2.5 and 2.6) I really do not want to do that anymore. The development team are off on some kind of flight of fancy and they are not listening to what the people who actually have to use WordPress want.
Every recent release has had a significant amount of items in Trac disappear in the 24 hours before release without there actually being solutions to them.
It is highly irresponsible for anyone to be telling people WordPress XX released, upgrade now – you can’t be certain that the release is a stable enough version for anyone to be using. 2.6 is an example of just how unreliable wordpress has become. The permalink issue was a pretty major one and still is a major problem for some despite the release of 2.6.1.
There were also a lot of users who upgraded and were suddenly unable to log into their blog. Some were suggesting this was a cookie problem but when you try several browsers that you never had used to log into that blog and have the same problem, it is pretty clear it is not a cookie problem. But WordPress continue to deny this is an issue on the support forums – they keep saying it is the problem of those who own the blogs it has happened to. That is not a helpful attitude to take.
Go have a look at the support forums and see the amount of problems and issues and trouble everyone is having – in a lot of cases they never get any kind of response. How about hiring some paid staff to work in those support forums, WordPress? The support people do not get a cent. They do it for love, and a lot of them are real cranky. 🙁 No wonder as they do cop a lot of abuse but part of the reason for that is WordPress are selling “usability” and not actually providing it to the people who download.
2.3.3 was the best version of WordPress. It is a shame things have since gone completely haywire. I am not sure it can be fixed.
I think he’s saying that because you made a point he can’t possibly argue against, Robert.
That’s baloney, and you would know it if you bothered to read my arguments that he can’t seem (or refuses) to understand.
But it serves your argument to agree with him because you’ve decided you hate WordPress.
I’ve had none of the problems you describe about not being able to log into my blog ever. But if I did, I would just hack the core code. I have learned a few tricks that will always let me back into my own blog if something went really wrong.
I don’t need fancy plugins to get me back into my blog or to reset my password. I know about browser problems, such as what Firefox 3 has with cookies.
Anything I come across that I think the WP community should know, I blog about, and if people google their problems, they’ll usually find someone with the same issue and sometimes a resolution.
Why should WP employ support staff? It’s FREE software.
A self-hosted WordPress installation requires technical skills to manage. If you don’t have them, you need to ask around and learn.
In my opinion version 2.6 is the BEST release of WordPress. I haven’t tried 2.6.1 and I don’t see it necessary to upgrade, having read the changelog.
If you can’t get WordPress working, I think that says more about your lack of ability than WordPress’.
We’re cranky because of people like you who seem to think that you’re entitled to support for a piece of FREE SOFTWARE.
Look, if a self-hosted WordPress is so burdensome to you, then please, stop using it. I’ll be the first person to tell you that. Use something else. Use WordPress.com. Use Blogger. Use Joomla, I really don’t care what you do.
But unless you’re contributing code to the codebase, unless you’re participating in the development of the software itself, unless you’re on trac reading patches and commenting on others, unless you’re on the mailing lists.. unless you do those things, then in my opinion, your comments are worth precisely zero. Those are the only ways to contribute. And notice that I did not include “bitching” on that list. You’re free to complain endlessly, but that doesn’t and won’t change anything.
WordPress needs doers, not talkers.
Umm… would it not be a good idea to *also* mention all the people who actually contribute (even limited) time to post a (usually helpful) response to questions on the Forums, which includes moderators like yourself of course, in addition to all the code experts?
Anyway, I can understand why people get cranky on the forums, because a very few posters demand an unrealistic amount of attention, but for a third party, this doesn’t make reading the responses any easier. I have great respect for one user for their obvious knowledge of the inner workings of WordPress and willingness to reply to people, but sometimes my respect for them diminishes exponentially when I read extremely cutting (even if helpful) and sarcastic responses to a seemingly benign and un-demanding question.
I’ve been guilty of this myself to an extent, but hopefully less so after reading Mark Ghosh’s article about “Be Kind, Educate”. I’m pretty certain most people don’t expect support from the official staff precisely BECAUSE WordPress is free, but it’s still nice to know there’s a place to ask questions.
Anyway, feel free to safely ignore my comment, as it’s clearly worth zilch.
Those people who do support are indeed very good at what they do, and deserve mad props. However, doing support is not the same as actively improving the software, nor really what I was talking about.
The AnonCoward above (whom I was replying to) falls into a whole class of people I’ve seen on the forums whom I think of as “griefers”. Yes, in the same sense as on WoW or other online games. Basically, they just like to complain without actively helping in any way. You see it over and over, the same people complaining repeatedly about the same things, and no matter how much you tell them how to contribute, they don’t.
Eventually, you just end up ignoring these people. Their opinions are worth nothing because they refuse to participate in the process. They just want to complain, nothing more than that. They want to cause grief. And yes, they can make people cranky.
But on the whole, I’ve also noticed some people being overly sensitive. Somebody making a light joke can easily be misconstrued as being sarcastic or (one of my new favorite words) “snarky”. Some people just need to learn to read text better, IMO. A factual response can be seen as cold. A simple or blunt answer can be seen as sarcastic. This is not usually intended that way, it’s often simply a matter of efficiency. There’s a lot of people asking the same questions over and over and not enough people to point them in the right direction.
My bad for misreading your point. 🙂 A few of the replies I’ve read would shock even the less-sensitive (and send the over-sensitive ones into bleating mode) just because it really seems so unnecessary, even though I could understand why the tone was so harsh and sarcastic, it made me feel bad for the person asking a polite and straight-forward question.
IMHO, efficiency is fantastic, but at the end of the day, there are humans at the end of the line. If a less blunt approach can encourage these users to stay a bit and help out, then all the better. But in all honesty, I would not be the one to stand up and point this out to ‘user x’ in my example. I’m far too chicken for that 😉
Otto – why would people be doers? To make money for Automattic?
Where did the $1.1 million and $29.5 million worth of venture capital funding go? You guys in the trenches aren’t worthy of being paid a salary when you put in blood sweat and tears supporting people? I just don’t think that is fair.
If WordPress do not want the average Joe to be able to download their software, then remove the download link and stop pretending the software is easy to use etc.. You know why they let people download it? Because those figures look mighty nice – and that is how you get that kind of funding. But they are letting you guys pick up the pieces, and that is not fair. Especially when they don’t pay you anything for doing it.
This is just my personal opinion, but I believe they’re using the moderators in the support forums as well as all the doers. Why isn’t someone(s) with a salary from Automattic taking some of the weight off the shoulders of the support forums? Why don’t they try and organise things a bit better to make it easier for you guys?
It makes me absolutely furious that the support people are not being paid. That is just poor form. 🙁 The support people are constantly hammered by people who simply don’t understand that the software they have downloaded and installed isn’t useable like they were told it was. The support people have a lot of knowledge and they are able to help people but there is such a huge workload, people asking the same questions over and over instead of searching (that has partly to do with the layout of the forums also) and everyone is just plain frustrated – those trying to help and those looking for help.
That includes you, Otto. I know you’re a good guy. I’ve seen so much evidence of it over the past year while I have been reading the support forums. Lately some of the posts from you have been so angry, and I’ve read more than enough posts from you on the support forums to know that isn’t who you really are. You bend over backwards to help. I imagine the cranky is coming from the pain of doing that constantly.
The title of this post should be – stop blaming the support staff, and put the blame where it belongs – on those in charge.
The bottom line Otto – we actually agree. I said – WordPress are selling “usability” and not actually providing it to the people who download. You said here – Running a website is not a follow-the-directions operation. You need technical knowledge. So the question is –
Why is WordPress allowing people without technical knowledge to download something that requires it, thus putting stress on unpaid volunteers to support those people without technical knowledge?
Do you think they are releasing things before they are ready to be released? I believe that is the case. More time in testing = less issues = less people in need of support, right?
As you say Otto, I probably will end up walking away from WordPress. I’m hanging in there and hoping at the moment. I don’t have that technical jargon necessary to do what you suggest though I do keep a close eye on Trac a lot of it is way over my head.
It is extremely disappointing to me because I moved over from Blogger and yes, when I did that I was a clueless unskilled person and knew nothing about php etc. The learning curve is huge and I’ve been willing to put in a fair amount of effort, I’ve learnt a heck of a lot, but it still isn’t enough.
So I can see why people not willing to try and not wanting to learn who downloaded this thinking it would be simple are very upset when they find out that they need to know a huge amount of technical stuff in order to run their website, and they have to keep updating it all the time and when they update it things break and they have no idea how to fix it because they don’t have that technical knowledge.
Anyway, I’m sorry Otto. I hope you’re not too mad at me for saying what I think – that is what bloggers tend to do. I’m really hoping someone “important” might be listening and hear what I’m trying to say.. but I would hate to think you were upset with me in the process. I have a huge amount of respect for you and the massive amount effort you put in. I am sure you feel a loyalty to WordPress but where is their loyalty to you and the others working for free in the support forums, bearing the brunt of the clueless? 🙁
Wow. I don’t even know where to begin… That’s a lot of text. 🙂
First, WordPress is FREE software. It’s open sourced, under the GPL. So is the mu.wordpress.org software, which runs WordPress.com. Automattic doesn’t make money off the software, they make money off their wordpress.com services. That’s where the VC money is, on the service. Separate the service from the software, dude.
Why do people program for Linux? You do know that Linux is free too, right?
Next, WordPress is indeed very easy to use. However, nobody ever said that running your own website was easy to do. The average Joe who can run WordPress, without any serious knowledge beyond setting up a website. However, fixing problems may require advanced knowledge. I can drive my car, but I can’t rebuild my engine (yet).
Also, I don’t want any money to moderate the WordPress support forums. I volunteer there because I find it fun and I enjoy it. So does everybody else. I also contribute to the WordPress code base when and where I can.
You’re missing the connection between Automattic and WordPress. WordPress is free software. Automattic is a separate service closely tied to it, but that doesn’t change that WordPress itself is free and built by volunteers. The fact that Linus Torvalds gets paid to work on Linux doesn’t make much difference as far as whether the software itself is free.
No, I don’t think they are releasing WP too early. I use the latest cutting-edge bleeding versions on my own sites, and trust me, the final product is *well* polished. A few minor bugs are bound to slip through, and I think people are simply too bloody serious about it. Take the recent login bug after an upgrade. Clear your cookies and you’re fine. But some people are all-up-in-arms over that one. Too much free time, those people.
What you say about the learning curve in moving from Blogger interests me though. I found Blogger totally unusable because it was so complicated, with that freakin’ strange template syntax. I switched to WordPress and learned enough PHP to get by inside a week. Within a month I was contributing patches to trac. PHP is probably the easiest language to learn that I’ve ever seen.
On the whole, I think that early versions of WordPress, being very simple, got a lot of people using it and blogging, and those people were non-technical. And yes, non-technical people are going to have a rough time upgrading and fixing things, because they don’t read the documentation and/or they don’t follow directions. There have been problems, but mostly minor ones with simple fixes. I’ll give you the obvious example: PodPress 8.8 works with WordPress just fine by adding 2 lines of code to a file. I even posted it on their forums. And yet the number of people still rolling back to 2.5 far exceeds the number of people patching the thing. Too technical? Adding two lines to a file?
No matter how simple you make something, it will be too technical for somebody. That’s just the nature of the beast, really. For those people, there is WordPress.com. They should use that instead.
Now I can see how you get so much done – you’re a very fast typist! 🙂
I think one reason people are hesitant to add lines to a file is because they are afraid they will break things. To most people that code looks scary to start off with.
Blogger was a lot easier as far as actual blogging – the templates are much easier on WordPress.
I know you say you don’t want any money but that doesn’t change the fact that you and the other support people deserve to be paid for your efforts.
I like the car example – to give you that example from my point of view.. you are told that your tyres need replacing (you need to upgrade), you go in and have that done (upgrade) and as you drive off you might be lucky and everything goes fine. If you’re not lucky, a number of things could happen. The steering wheel might come off in your hands. The brakes might not actually stop the car. Perhaps all the doors fall off.
These are not things you were expecting and you have absolutely no idea what to do. You panic, and you go looking for help. If you’re like me, you will search the web – hopefully the error has given you something you can enter in as a clue. If not, you type in something like “doors fall off WordPress 2.X.X fix” and if that doesn’t work you search the support forums. Which in itself can be a bit of a challenge.
If you’re not like me, you go to the wordpress support forums and you post a brand new thread, adding to the 11eleventy1one other threads asking the exact same question only each time the person is wording it slightly differently. Or you might find a thread where there seems to be a similar problem and post in there, trying to keep the issues in some kind of logical order.
Unfortunately the support forums are not divided up into 2.6 and 2.5 and 2.3 etc – I think if they were, it would make it a lot easier for people to find a thread with a similar issue to their issue. I also think showing a few more threads per page by default might help. Also I have noticed people are posting stuff all over the place in no logical fashion. Having to go in there and deal with just that aspect of it daily is worth huge $$ in my opinion.
I also think you’re spot on re early versions being very simple – that is one reason a lot of people started using it. If those people could stick with those versions rather than having to upgrade to the ultra technical version that would be brilliant. For example, I’d love to stick with 2.3.X – I am used to it. I don’t know why they couldn’t just give us the security fix and let those of us who wanted to stick with that while they went off and made 2.5/2.6 kick butt and extra reliable.
WordPress.com doesn’t do all the things I need my blog to do now, though. You see I have got used to the plugins – I need them now. 🙂 There’s no in-between option for those of us who want to get a bit technical but not *too* technical.
I know you say it was a cookies thing and you can’t replicate it but a good (and very technical) friend of mine was doing an upgrade for a friend – thus had only ever logged into that blog with firefox. When the problem happened they tried to log in with both Opera and IE, and neither of those had cookies for that (or any other wordpress) blog.
At the end of the day reliability is pretty important to bloggers. They freak out if their blog goes offline. People do get very upset when they can’t log in to their blog. For a lot of bloggers, this is how they keep in touch with their family and friends and also their readers, for many this is how they earn a living these days. They do take it pretty seriously. And unfortunately the support staff cop the brunt of it.
It isn’t fun to read for any of those keeping an eye on the forums. I do spend a fair bit of time there but I don’t post as I don’t know enough to be able to add much of use. I wish I did, though. You guys could do with a hand.
I currently host over 40 blogs for people who moved over from blogger – a lot of them based on how enthusiastic I was about WordPress. Some of them have picked up the ball and taken off with it when it comes to the learning curve. Some of them struggle with it, working some things out but sometimes end up asking me for help (which I am happy to provide). There’s a couple who moved over from blogger and show no interest in trying to learn how their blogs work or how they can fix things when they break. The majority of them would never have made the move without my help to start off with.
So I feel a bit responsible for being so enthusiastic and encouraging them to move over – that is one reason why I have been upset with the recent versions. But we were all told WordPress was simple and easy to use, and we could have a lot more control over things. That’s why we switched over. 🙂
Yes, well, to paraphrase Stan Lee, with full control comes full responsibility. 😉
And I think that 2.6.1 is super reliable. I’ve never had it fail. I’ve never had a problem with it. In the end, I’m not sure why you have had problems and I have not. To be fair, I know quite a bit about it and can easily fix it if it breaks, but my live site has never broken due to an upgrade or do to anything that I did not cause. It just works. All the time. Never fails.
So, what more can I say? You see the software as unreliable in some way. I don’t, I see the users as the more unreliable aspect. They’re far more likely to break it through a mistake or by simply not knowing what they’re doing. How can you fix that through software? You can’t.
No, you can’t fix the users being unreliable via software. What you can do is make it clear to the users that they need certain skills to be able to use a self hosted version of WordPress and if they don’t have those skills then please don’t use it.
Then perhaps WordPress could create a more basic version which is –
– a stand alone product
– not to be upgraded ever (other than simple security upgrades)
– easy to use
– without all the complicated extras
This software would allow less technically minded people to have a blog with –
– static pages
– image uploads
– plugins but maybe not such a massive range of plugins
– templates
There’s a lot of people out there who want to be able to blog. Compare that with the people out there who have the kind of skills you believe they need to run a website – there is a massive difference between the two numbers.
Who does WordPress want to make this product for? The coders with the kind of skills you’re talking about or the general public, or both? If the answer is the general public or both, then I think the powers that be need to have a rethink about how they are approaching this.
The users are unreliable and that isn’t going to change, unless WordPress can create a magical implant chip which can be injected into us that will teach us all the programming stuff we need to know. And I don’t think that is going to happen anytime soon. 🙁 Though I wish it could! 😉
There already is a version of WordPress for those people who don’t want to administer a website, and that is wordpress.com. They can get an account there, create a blog, change the themes, even get their own domain name for a small fee (no more than buying a domain normally costs).
Or you can hire somebody else to administer your website for you, while you just blog. There’s a whole service industry waiting there for that sort of thing, if you’re correct.
The WordPress team makes WordPress. That’s it. It’s free software, if you think there’s a market for this sort of thing, then do it. Anybody can use WordPress for whatever reason they want. That’s the beauty of free software.
What you can do is make it clear to the users that they need certain skills to be able to use a self hosted version of WordPress and if they don’t have those skills then please don’t use it.
Well I pretty much thought that situation was obvious to most, but I guess not obvious enough to some. WordPress.com was established to cater for those users who do not want to be bothered with the tech details.
Then perhaps WordPress could create a more basic version which is –
– a stand alone product
That is precisely what a self-hosted WordPress installation is.
You want a more basic version? Write it yourself. Oh, wait, you can’t do that. Tough luck, I guess.
– not to be upgraded ever (other than simple security upgrades)
Good luck with that. You’ll be left in the stone age of blogging forever. See how many people want THAT.
– easy to use, – without all the complicated extras
So go write it. Fork whatever WP version you like, 2.3.3 I believe, and take it further. It’s all on YOU now.
Who does WordPress want to make this product for?
Non-whiners who are just damn grateful that they are getting quality software that is continually being improved.
You don’t like what they have to offer? Fine. Go find something more suitable, but for the love of Christ, quit yer damn bitching! WP owes you nothing!
I think the powers that be
WordPress developers are not a government or an authority. They’re just people who have the ability to develop great software.
If you want the POWER to determine your own software destiny, then you need to learn to CODE.
that will teach us all the programming stuff we need to know.
Dammit, man, you just want everything to be DONE FOR YOU, don’tcha?
The onus is totally on YOU to LEARN how to CODE, if you want the power to create your vision of what you want the software to do.
I did not learn how to code overnight. It took many hours of work. You don’t need a college degree to learn how to code, but you do need to be willing to invest a substantial amount of hours. There are loads of tutorial programs online that will get you started. There are reference manuals, and there is sample code.
But you basically want to sit back and throw out what you want and others must scurry to provide it for you, and you are not willing to spend one red cent on the development cost.
How is this anybody’s problem except your own?
As someone who was with 2.3.x for ages on one site, and only just changed over yesterday to 2.5 (last jump was 2.1 to 2.3 so I guess I’m waiting for 2.7) I’d have to agree that 2.3 was really really good 🙂
So uninstall 2.5 and put 2.3.3 back. What is stopping you?
Well I can think of a whole bunch of reasons.
Ouch 😉 So can I, which is why I changed. Didn’t mean that 2.3 wasn’t good though ~~
It is the user’s responsibility to ensure that the plug-ins they have in place are compatible with the latest version of WordPress. Plug-in docs show you the WP version it is compatible with. Having a test site that mirrors your current live blog also helps.
Right. And I’d really like to see the new plugin installer built into 2.7 actually use that information to give the user a warning saying “this plugin only claims compatibility up to 2.x, install anyway?” That would at least shut some people up.
Let us keep the comments on topic and stay away from personal jabs and name calling.
@ Mark, Thank you for saying that 🙂
@ the Whiners and Blamers – If you guys put as much effort into your WordPress installs as you do into writing massively long whines and bitches here, maybe you wouldn´t be having so many problems.
@ the WP lovers (of which I am one) keep spreading the WP love.
countzeero out!
Who to blame? A most interesting question, because I am a plugin addict. I admit it, I love my various plugins, and I know nada about PHP, programming, but I can ftp to my site, add my little goodies and there I go, blogging away and hopefully making some cash.
However, when things go wrong, ouch. I scream, stomp my feet, but here is the thing, the plugins i get or select, are from the WordPress Repository.
To me, it is simple. When I go grocery shopping, I buy the store’s products, or simply put them in the cart if they are free, but at the same time that I buy the Store’s specialty products, I find I need some bread and milk. I grab those too, go home and open the milk for a swig and find it has gone sour, I open the loaf of bread to find it is moldy.
Do I go running to the bakery that made the bread?
Do I go running to the dairy that processed the milk?
Nope, I go back to the store and holler and scream.
I don’t go snooping all over for my plugins, I get them at a site in the WordPress site, the one THEIR link takes me too. So while sure, they didn’t make it, they are the one’s offering it up to all us who use their product.
They have some obligation to protect the consumer, just like my grocery store has, to not put expired milk on the shelf for sale.
I don’t blame WordPress, I just feel they should do what any retailer does, whether free or not, clearly show what is up to code, what isn’t.
Flag the plugins, or turf them if there are complaints, but still offering podcast for example, gives an implied approval, that it would work. If they know it doesn’t, then remove it from the shelf until it does.
And make it easier for us NON GEEKS, to let them know of the problems with a plugin, so we can keep them informed, without a whole slew of go here, go there. In any store, their is a customer service counter. Why not at wordpress?
my 2 cents.
1. They have some obligation to protect the consumer, just like my grocery store has, to not put expired milk on the shelf for sale.
Nope. They have ZERO obligation. Read the GPL.
2. but still offering podcast for example, gives an implied approval, that it would work. If they know it doesn’t, then remove it from the shelf until it does.
Why? PodPress does still work for some versions. And also, by leaving PodPress available for download, someone else can come along and grab the code, edit it and make it work with the current version of WordPress.
This is NOT all about you little consumers who want PACKAGED goods. This product is for DEVELOPERS who enjoy using Open Source Software to achieve their own ends.
If you want a fully developed consumer blogging package with support and all the bells and whistles, go and find a COMMERCIAL product and PAY FOR IT.
You just don’t understand how OSS works. That is the REAL VALUE of this thread:
educating people as to what they can and cannot expect from WordPress.
Silly me, hear I thought wordpress was for people, all kinds of people, not just ‘developers’. Someone should have told the founders that, so they wouldn’t let us ‘little consumers’ in to play in their ball park.
Dude, we’re not removing “products from the shelf”, to use your supermarket metaphor, because a “consumer” tried it out and it broke their installation.
The code is there for developers to download and make work if they want it.
I think there is a fundamental misunderstanding of the model of license and distribution that WordPress uses.
Nothing is guaranteed. Use this software at your own risk. If it breaks, fix it yourself, if you can or discard if you can’t. But don’t bitch when stuff doesn’t work. You do not have that right.
If something doesn’t work you have a right to bring it to others’ attention, but you do not have a right to SCOLD anyone.
Getit now?
Boy, oh boy. If this fellow is a spokesperson for WordPress, they need a new Public Relations team.
I’m not a spokesperson for WordPress.]
However, I am expressing the truth of the situation. I guess the truth is unpalatable for you to hear?
Would you rather be lied to?
It isn’t a question of whether or not you’re “expressing the truth of the situation;” it’s the way you go about expressing your “truth.” I think you need to read this book.
To heck with your book. I’m mad. I am frankly offended by the people who think they are owed something by the developers of FREE OSS software.
Automattic has gone to a huge amount of trouble to accommodate users who lack technical skills by providing WordPress.com. You can even host a domain on that platform.
And I am offended by the people who wish to impose restraints on improving the self-hosted WordPress software because they’re not smart enough to figure out how to use it properly. Boo hoo. Cry me a river.
My apologies. You don’t need a book on manners; you need a book on anger management and another one on civil discourse – you probably need an enema, too.
You sound rather worked up yourself. Now enough of this talk of enemas.
I don’t want to get to know you that well. Haha.
Just for the record, I too am not a spokesperson for WordPress. This post was created by own my own perspective and opinions regarding the situation.
On the Supermarket metaphor:
I believe the metaphor is wrong. The WordPress site is more like a Mall — one place to go to that offers various stores — , and the Plugin authors the stores in the mall offering their little plug-in products.
And, it does not take ANY technical knowledge at all to understand what “compatible up to version x.x” meant. It is just like reading the expiration date of the milk you bought at the supermarket.
Add my two centavos to your two cents.
Some people are blunter than others in the comments 😉 I bet Jeff never thought this post would generate SOO much commentary!
Can I all it the ‘Trust’ game? We trust WP to kindly supply us all with a solid platform (and that is all); we trust plugin authors to at least be kind enough to give us code that is working and secure (for the versions they want to support); and that the people helping out by writing articles/educating others/helping on the forums etc and sharing their experiences have every good intention in trying to make the WP community an even more knowledgeable group.
Personal jabs have no place here. The “you, you, you” can be such a tiresome read 🙂
p/s: I went to look up what “Open Source” means, and came across this article, which says the definition differs a little depending on which perspective you’re coming from.
I trust WordPress and most plugins I come across, but if something doesn’t work out I don’t cuss WordPress out. I just fix the issue and blog about my experiences so that others can avoid my pitfalls.
I reckon that is the correct way to approach things, not the way some people in this thread are.
I have read this and read through a few of the comments. I thing it is good that WordPress does frequent releases, but I do think that most of the releases that have been done have really offered little in the way true forward movement for the hassles involved. I would rather see a short wait and do a major release 4 times a year a bug/security patch when required. That would allow for greater testing an verification and testing, as well as a slighter longer period for plug in authors, who are rarely doing such as a full time job, to respond and fix things. For those few who think plugins are a waste – do not use them. And if you lost data, that is your fault for not backup your file and database for installing – can’t really complain if you did that – harsh as it is – your own fault.
I think one of the biggest problems is a lack of education on backup before upgrading.
When it comes down to it, there’s so many people using WordPress that there is no one simple way to get an important message across to all of them at once.
There is the dashboard but that requires people to click on the posts to go and read them.
I agree with you about the releases Ray – for me 2.5 was a huge step backwards especially re widgets and moving stuff in the write screen. I don’t know who thought these changes would be a good idea but they made things take longer and made things more difficult to do – not just for me but many people who use WordPress made that same comment.
I wish that some of the older versions (ie 2.3.3) could be supported for longer. That way the people who are using wordpress because it was simple could keep using it without having to worry about all the wickety wack new features they don’t want or need..
Yeah to many updates to soon is a big problem with WordPress. If they want to do that many updates they need adopt an approach similar to the open source folks that are doing Ubuntu Linux have. They do regularly releases, but every 4th or 6th one is a long term support release. Releases in between have support until basically the next release comes out. That LTS version though has support for basically 3 years and is considered the stable you really want to use this in your server room kind of version. That stable version still gets security patches and such, but it does have major changes down in deep in the core that will typically break things you have set up and running on the system.
Ubuntu has a two-tier structure release cycle because it offers commercial support packages.
I think if WP were to follow suit and also offer commercial support, they may be inclined to restructure their releases too.
I also miss the drag and drop widgets of 2.3.3. While you can drag and drop within a sidebar, you can no longer do it between different sidebars, which does introduce inefficiency.
However, the new system allows for more sidebars in an uncluttered view window. So it’s a trade-off.
Since it’s my statement you quoted in the thread of this post about the responsibility of WordPress and Podpress, let’s just clear the air on that – you quote that much of a persons statement, whether in print or online, be prepared to reference the author. Either edit your post to remove my statement or provide a link back to my site – ’nuff said there.
Now, onto the “release schedule”. WordPress has had 5 releases by your own admission for 2008. That’s one almost every two months. Also by your own count, that allows for about 22 days of testing. Sorry, but open sourced projects need to allow more time for testing simply because open sourced developers do it in their spare time This notion that they can knock this out in 22 days every 2 months is asking and expecting too much of the community. Simply put – just slow down the updates and you will have less breakages, more stability, and in the end – a broader and deeper user base.
If I had to update Windows or my mac with a major service pack every 3 months, I simply would not use the OS. Windows has had 3 now for XP – in SIX YEARS!!! SImple math says WP is updating too often. SLOW IT THE F DOWN!!!
First off, my intention was to never provide the comment authors identity as the identity of the person who wrote the comment does not matter. It is the line of thought that came out of the comment which formed the basis of this post. However, it turns out that I linked to Xfep.com for another reason in this post and that is when I noticed the comment which I quoted ended up being the one on Xfep.com. I’ll go ahead and edit the post to address who made the statement, but I don’t think it really matters who said it.
I’ve given the update cycle some thought and I’m leaning on the side of the fence which is too many major releases on one year. I’ve been thinking that instead of three, having two a year should be sufficient with minor releases addressing bugs and small feature tweaks.
With that said, we could take out the .1 releases to be honest since those are the ones which the majority of time, do not cause the breakage. If you did that, then I don’t think the release cycle looks that bad but those are updates that are needed more so than the major versions.
I believe the statement was made in the latest announcement of the revamped WordPress release schedule (sorry, can’t quote the exact date of this one) was that each new major milestone release (non .*) would have less of the “major changes” of functions and new features that were found in previous major milestone releases. This, of course, would allow the team to devote more time to substantial bug fixing and testing of the relatively fewer new features before each release.
Still in all, by what I see, the biggest mistake made about the release schedule is attempting to force it into a rigid shape. Although some set pattern of releases should be kept in mind the actual schedule should remain flexible in nature. If the team feels satisfied with either a milestone or a *.1 release, then don’t wait 2 weeks for the due date to roll around (normally, they don’t but…). By the same token, by leaving the schedule flexible, if the team feels uneasy about a release (no “warm fuzzies” felt)and/or they feel more testing and feedback from users is needed to just downright “Hey, this frickin’ new feature just ain’t ready…we gotta fix it or dump it but we can’t release it! Somebody make a command decision here!” can easily be taken into consideration without the pressure of a deadline hanging over their collective heads.
Yes, the “do-it-yourself’rs” will have to go along for the ride but the simple fact is that the decision to keep a WP install as up to date as possible is up to the individual user and each and every user is responsible for their respective site and no, you don’t have to be a programmer or be fluent in code to maintain your site. Just be savvy enough to do your homework before upgrading to a major new release.
Looking at the bleeding release version (2.7-hemorrhage) it looks like WP is going to build in a feature to automatically upgrade the core from within the WP dashboard which will make upgrading significantly less painful for those doing it manually.
There is also now a facility to install plugins directly from the WordPress repository, plus delete plugins, all directly from within the dashboard.
That facility has not yet been extended to themes, but I expect that is on the cards too.
These new features are going to make it so much easier for WordPress users to keep their product up to date.
I understand your school of thought at keeping things as neutral as possible, but when you quote that much of an idea or thought and do not reference the source, it’s called plagiarism. This is still illegal in this country and the ramifications of it include suspension and/or expulsion from school if a student and termination from employment if a professional. As a blogger, you write with much more leniency because there is no governing body. Nevertheless you still have a responsibility to cite the source when copying that much text. If you want the idea to get across, then paraphrase. If you want the actual text: cite the source.
On the matter of the updates, two per year is still much higher than the three major updates Microsoft has pushed out in the form of service packs in the last 6 years. This, when combined with the fact that the open sourced community is an unpaid community of volunteers, suggests that major code revisions should not happen on the same scale as proprietary software. I stand by my original statement that WP develoeprs push out updates and new code way too often.
By the way, for a primer on plagiarism, this may be a helpful resource:
http://www.plagiarism.org/lear.....arism.html
Jason, we will take your plagiarism complaints off line if you choose to pursue it. Please use the contact form.
It has nothing to do with the topic of this post and we need to stay on topic. Thanks for understanding.
@Mark – Apologies for that, I probably should have addressed that privately, as you are right – totally tangential to the subject matter.
FWIW – I learned from another source today that Matt actually did provide an advance copy of the update to WP to the plugin developer, as well as provide a fix that just has not been committed as of yet. This completely changes the context so my previous comments on the matter are effectively null and void, as it sounds more and more like WP did everything they could with PP to keep things humming. Thanks though for providing this venue for users, programmers, and developers to share and expand the knowledge base. Regards,
Jason
I agree and disagree with some facts given here.
Yes, the release dates are too fast. Maybe the update versions require a more faster release, but new branches tend to modify everything so plugins and their authors have a hard time trying to catch up every single detail “improved” for the next branch.
Take for example the difference between 2.5 and 2.6. The changes are radical, so a lot of the plugins may break up.
If you remember a way back time, 2.0 came from 2.0.1, 2.1.0, 2.1.1, 2.1.2, 2.1.3 and so till 2.3.3
It’s not the WP team or the users fault. Both are wrong.
First the WP Team for launching a new branch so close to another without further testing (leaving this to other users to handle)
Second “The Users” have some fault too for installing a new branch just as it surfaces the wordpress.org homepage. You should know by now that .0 always comes buggy and you should better wait till .1 is released.
Well, this was my 50/50 fault giver xD
Silla!
You guys are crazy.. I mean, first off, WHO CARES if existing plugins aren’t compatible with the latest and greatest version of WordPress. Its the plugin author’s responsibility to keep up on updates, otherwise take their plugins down from the general public. Its not Automatic’s fault that certain plugins don’t work with the newest plugin releases, sounds to me like those plugin authors are just playing the blame game here.. 2 months is PLENTY of time between releases. If plugin authors would write their code clean enough to begin with, they wouldn’t have to keep updating their plugins in the first place. More then half the plugins out there, haven’t been updated since the 2.1 days, and they still work JUST FINE with wordpress 2.6, probably even 2.7, so it sounds to me like a whiny few blaming automatic for their own problems is what it sounds like to me. Personally, I say, the release schedule is awesome just how it is, and if a good handful of plugins, out of 800+, don’t work with the latest version, who gives a crap! *smiles*. seriously, sounds like a bunch of whiny self centered developers if you ask me, blaming someone else for their own development problems.
Besides, something else to consider, if your plugin doesn’t work with the newest version, its not going to make any difference if the next version is released in 2 months, or 2 years, its still going to be incompatible, and the truth of the matter is, if the release schedule was haulted, plugin authors would still be complaining, rather its 2 months or 2 years, for half the plugins out there aren’t even updated in 2 years, much of less every 2 months. Agagin, I like the release schedule, because that gives us users the ability to see if the 800+ plugins that are out there are still in development or not. More then half of them stopped development eons ago and still work with the latest and greatest versions of wordpress, so it sounds to me like plugin authors are just blaming someone else because they have to get off their butts and update their plugins in the first place, rather its once every 2 months, or once every 2 decades those same people are still going to complain, so I say screw the comments and keep the schedule how it is
seriously, sounds like a bunch of whiny self centered developers if you ask me, blaming someone else for their own development problems.
Name calling won’t change things and is not very constructive.
I think the point was made by a few posters already that some changes that could affect plugins should be documented (and I don’t mean through Trac, because that doesn’t call out a particular change).
Whether it’s a change that could break a plugin, a new way of doing things that plugin developers should adopt, or just new functionality that some plugins might be very happy to adopt, it would be very helpful to developers to have something posted at release time – or before – that identifies the changes and recommends how plugins (and even themes) in general should deal with them in their code.
WordPress’ codebase is large, and to have to dig through Trac, or dig through all the code, or Google and search, or to test every single possible interaction with that code, is much less efficient than simply having those changes and recommended practices identified (summarized) so we know what to focus on. The “list of new features” aimed at users is not quite the same thing.
Non-developers may not understand this issue and think plugin developers are being unreasonable, but as a very experienced developer, I know for a fact and from experience that the best way to coordinate a change across complex software components is with communication, not with a “handoff” of responsibility. And I am not accusing the core team of not caring about the plugin developers, because I’m sure they do… my suggestion is simply that they provide a few extra deliverables with a new release.
Totally agree.
It’s not the release schedule, its the lack of succinct documentation on changes to the back end that I have a problem with.
You have to accept that in community development, it’s easy to get volunteers to work on the cool and exciting bits, but not so easy for the boring things like documentation. This is where Automattic have a role to step in and fill the gap.
After reading this post and a couple of comments. (I admit I only read a couple of the comments.) here are my thoughts. The WordPress Team does a fascinating job. Not only do they manage to release great software multiple times a year, but they stay on top of updates/bugs for each of those releases. I agree you cannot expect more out of a development team. One good point I seen in the comments was the adaption of some plug-ins for the core, however, that is also impracticable. Another thing that is getting overlooked here is bloating. WordPress is perfect because it don’t have all the bloating. Adding the plug-ins to the core, and guess what? WordPress will bloat.
I believe there is a couple true issues, that should be addressed. One plug-in developers do not always stay on top of the development game. Believing that WordPress won’t change the main core enough to effect them. Another issue is, going to the wordpress/wordpressMU/Buddypress communities, seems to be a waste of time. After posting an issue in the forums (WordPress), I have waited months for an answer from anyone and have yet to get that answer. Buddypress is just as bad, however they seem to redirect you to WordPress’s forums, or to a theme developer, where once again, no answers. So, there is some support organization issues. Another issue is all to often Themes. Theme developers don’t really support their themes, and digging information out of developers can be an absolute pain.
In closing, maybe theme/plug-in developers need to learn to support their own software. If wordpress puts out an update maybe they should do their own testing, and make sure their software, which requires WordPress, works with the main core. And let me say this too. WordPress doesn’t make money off of plug-ins and themes, the plug-in and theme developers do.
I agree with you on the point about support, John. I have never, ever…EVER gotten a reply to my queries for help in the forums. I read where people rave about WP support and I’m like, “WTH?” But I still stand by my original comment that WP is awesome for the “money” and I think WP fans certainly know what I mean when I make that statement. But I’ll translate for those who don’t know. WP is lightweight, secure, stable, and FREE! Unbelievable. You have to wonder..how do they do it?
I kind of strayed a little bit on my post I guess. Another valuable point to be made is this. It is always a good idea to have a DEVELOPMENT server, and a LIVE server. Reason being, you can test out the new releases, before they ever go live. If it breaks your website on your DEVELOPMENT server, then it will your live server too, therefore, you can leave the live server, until you have worked out the bugs on your DEVELOPMENT server. Then do the full update on the LIVE server.
I do this personally. I have a development server on my home pc that I update first. I work out the bugs, and then I update the live server. This then takes some of the pressures off of the support team of both WordPress, and the plug-in developers, giving you a little more control over what is going on with your server.
In order for this idea to work however, the people who do know what the heck to do, would have to be a little more forth giving with information. The ones that don’t know what to do has to have some patience, and… the ones who just don’t care should hire someone or resort to Worpdress.com.
Truely, these kind of issues can be resolved by communicating. I thought that was the whole point behind WORDPRESS. It gives us the platform to communicate. When will we start using it?
Regarding your first issue, how on earth do you get third party developers to develop at the same speed as the core of WordPress? I understand that education, more documentation, easy referencing, etc. could all be done to make the lives of developers easier but at the end of the day, it’s on their shoulders to make sure they are on the up and up of what’s going on with the software they are developing on top of.
It’s pretty obvious to me after monitoring the WordPress Support Forum mailing list that all of the forum moderators/administrators who are volunteers take great strides into at least making sure someone gets a response. Maybe it sounds cliche but the fact of the matter is, the support forum has intense volume. Out of a guess, I’d say two thirds of the forum are new posts with a third being replies. So you’re not the only one not getting a reply. Just out of curiosity, what expectations did you have when you went to the support forum? I hope it wasn’t priority support. If you are redirected to the plugin or theme developer who by the way, would be the best person to ask for support since they created the darn thing and if they don’t answer you, that’s not the fault of WordPress, the core developers or what have you. That lies on the shoulders of the plugin or theme developer and that is who your disappointment should be directed.
This is a fundamental flaw in any open source script. The core is entirely independent of plugins. I’m not sure why and how the WP team will test working of “popular” plugins.
One solution is to support the fallback for plugins, if it is possible. Another solution is to allow plugin developers to catch up with the next release.
In any case it is going to be a complex and massive task for both WP team and plugin developers to co-ordinate together.