Weblog Tools Collection

235 Comments | Leave a comment | Comments RSS

1. 

   [...] has published an interesting post over at Weblog Tools Collections about the blame for plugin problems being laid at the door of the WordPress core team, and I think he has a point, but as a minor plugin author I also see things from a slightly [...]

   WordPress core at fault for plugin breakages | WP FUN — 08/24/2008 @ 3:38 pm
2. 

   what wordpress does for the blogging community is amazing, just imagine a world without wordpress…huh?..huh? scary!!!!

   [Reply]

   Neil (30 comments.) — 08/24/2008 @ 4:09 pm
3. 

   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.

   [Reply]

   

   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.

   [Reply]

   
   Jeffro2pt0 (163 comments.)

   August 24th, 2008 at 6:42 pm

   

   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.

   [Reply]

   

   Every hour? Isn’t that.. massive overkill? Or did you mean every day..

   [Reply]

   

   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.

   [Reply]

   

   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.

   [Reply]

   
   amolpatil2k

   August 25th, 2008 at 5:53 pm

   
   Richard Catto (34 comments.)

   August 25th, 2008 at 3:46 pm

   
   Ross (1 comments.)

   August 25th, 2008 at 12:44 am

   

   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.

   [Reply]

   
   Network Marketing

   August 25th, 2008 at 3:23 pm

   
   Richard Catto (34 comments.)

   August 24th, 2008 at 8:17 pm

   

   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

   [Reply]

   
   Jason (60 comments.)

   August 24th, 2008 at 9:33 pm

   

   You should use MT. They have all that crap built in.

   [Reply]

   
   Robert (32 comments.)

   August 25th, 2008 at 11:46 am

   Chuckles — 08/24/2008 @ 4:23 pm
4. 

   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.

   [Reply]

   Pi (1 comments.) — 08/24/2008 @ 4:28 pm
5. 

   > 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.

   [Reply]

   

   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!!

   [Reply]

   
   Neil (30 comments.)

   August 24th, 2008 at 4:54 pm

   

   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?

   [Reply]

   
   Jeffro2pt0 (163 comments.)

   August 24th, 2008 at 6:43 pm

   

   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

   [Reply]

   
   Gianluca

   August 25th, 2008 at 2:56 am

   no — 08/24/2008 @ 4:30 pm
6. 

   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.

   [Reply]

   

   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.

   [Reply]

   
   Jeffro2pt0 (163 comments.)

   August 24th, 2008 at 6:46 pm

   Chuckles — 08/24/2008 @ 4:30 pm
7. 

   Shorter Post For Certain Plugin Authors

   Your arm broken?

   [Reply]

   Alan Kellogg (1 comments.) — 08/24/2008 @ 4:32 pm
8. 

   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.

   [Reply]

   

   Nicely said.

   [Reply]

   
   JRivera

   August 24th, 2008 at 10:15 pm

   Jeff (11 comments.) — 08/24/2008 @ 4:58 pm
9. 

   (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. )

   [Reply]

   

   Better?

   [Reply]

   

   Much.

   Thanks.

   

   [Reply]

   
   Jeff (11 comments.)

   August 25th, 2008 at 3:28 pm

   
   Mark Ghosh (249 comments.)

   August 25th, 2008 at 9:54 am

   Jeff (11 comments.) — 08/24/2008 @ 5:00 pm
10. 

    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.

    [Reply]

    

    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.

    [Reply]

    

    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.

    [Reply]

    
    Jordan (3 comments.)

    August 24th, 2008 at 6:58 pm

    
    Jeffro2pt0 (163 comments.)

    August 24th, 2008 at 6:49 pm

    Jordan (3 comments.) — 08/24/2008 @ 5:08 pm
11. 

    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.

    [Reply]

    George (1 comments.) — 08/24/2008 @ 5:16 pm
12. 

    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)

    [Reply]

    

    Frank that is the overall issue I tried to represent in this post.

    [Reply]

    
    Jeffro2pt0 (163 comments.)

    August 24th, 2008 at 6:51 pm

    Frank (6 comments.) — 08/24/2008 @ 5:21 pm
13. 

    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.

    [Reply]

    

    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.

    [Reply]

    
    Jeffro2pt0 (163 comments.)

    August 24th, 2008 at 6:53 pm

    Jacob Santos (4 comments.) — 08/24/2008 @ 5:25 pm
14. 

    “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).

    [Reply]

    Brian Carnell (1 comments.) — 08/24/2008 @ 5:27 pm
15. 

    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.

    [Reply]

    

    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.

    [Reply]

    

    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.

    [Reply]

    

    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.

    [Reply]

    
    Richard Catto (34 comments.)

    August 27th, 2008 at 6:47 pm

    
    Jeff Chandler (260 comments.)

    August 27th, 2008 at 6:32 pm

    
    Stephen Cronin (20 comments.)

    August 25th, 2008 at 8:44 am

    Martin — 08/24/2008 @ 5:36 pm
16. 

    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.

    [Reply]

    

    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.

    [Reply]

    

    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.

    [Reply]

    
    Kirk M (36 comments.)

    August 25th, 2008 at 12:36 pm

    
    Jeffro2pt0 (163 comments.)

    August 24th, 2008 at 6:58 pm

    c0y0te (4 comments.) — 08/24/2008 @ 5:59 pm
17. 

    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 ….

    [Reply]

    Ron (1 comments.) — 08/24/2008 @ 6:18 pm
18. 

    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.

    [Reply]

    

    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.

    [Reply]

    
    Jeffro2pt0 (163 comments.)

    August 24th, 2008 at 7:00 pm

    Milan Petrovic (11 comments.) — 08/24/2008 @ 6:28 pm
19. 

    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.

    [Reply]

    

    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.

    [Reply]

    
    Pagani

    August 25th, 2008 at 12:40 pm

    mali (1 comments.) — 08/24/2008 @ 6:44 pm
20. 

    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.

    [Reply]

    Al — 08/24/2008 @ 7:00 pm
21. 

    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.

    [Reply]

    

    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”!

    [Reply]

    
    Pagani

    August 25th, 2008 at 12:46 pm

    

    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…

    [Reply]

    
    Caesar (1 comments.)

    August 25th, 2008 at 1:34 pm

    Lisa — 08/24/2008 @ 7:44 pm
22. 

    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.

    [Reply]

    JamieO (5 comments.) — 08/24/2008 @ 7:51 pm
23. 

    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.

    [Reply]

    Paleo Pat (4 comments.) — 08/24/2008 @ 8:02 pm
24. 

    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.

    [Reply]

    

    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.

    [Reply]

    
    Dave J. (Scoop0901) (5 comments.)

    August 24th, 2008 at 9:05 pm

    

    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.

    [Reply]

    
    Barry (12 comments.)

    August 25th, 2008 at 10:23 am

    Roger Theriault (2 comments.) — 08/24/2008 @ 8:09 pm
25. 

    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.

    [Reply]

    Lynn (1 comments.) — 08/24/2008 @ 8:10 pm
26. 

    @ 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?

    [Reply]

    

    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.

    [Reply]

    

    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.

    [Reply]

    

    Perhaps we should all be as great as you are. Hip hip hooray! RIchard is the greatest ever!

    [Reply]

    

    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.

    [Reply]

    

    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.

    [Reply]

    

    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.

    [Reply]

    

    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.

    [Reply]

    

    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.

    [Reply]

    

    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.

    [Reply]

    

    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.

    
    Richard Catto (34 comments.)

    August 25th, 2008 at 10:07 pm

    

    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.

    
    Robert (32 comments.)

    August 25th, 2008 at 10:09 pm

    
    Robert (32 comments.)

    August 25th, 2008 at 9:56 pm

    
    Richard Catto (34 comments.)

    August 25th, 2008 at 9:38 pm

    
    Robert (32 comments.)

    August 25th, 2008 at 9:12 pm

    
    Richard Catto (34 comments.)

    August 25th, 2008 at 8:36 pm

    
    Robert (32 comments.)

    August 25th, 2008 at 6:42 pm

    
    Richard Catto (34 comments.)

    August 25th, 2008 at 5:05 pm

    
    Robert (32 comments.)

    August 25th, 2008 at 4:41 pm

    
    Richard Catto (34 comments.)

    August 25th, 2008 at 4:01 pm

    
    Robert (32 comments.)

    August 25th, 2008 at 9:59 am

    Richard Catto (34 comments.) — 08/24/2008 @ 8:11 pm
27. 

    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.

    [Reply]

    Kalyan (1 comments.) — 08/24/2008 @ 8:58 pm
28. 

    I have to agree with this. It would be wonderful if all the great plugins that i use were all automatically compatible with the latest, safest version of Wordpress. But if they are not, then I will gladly disable those plugins until they are safe to use. If I find that I can do without them, then I will do without them. It’s unfortunate, but I don’t see it being up to WP to make sure plugins comply. I’d hope that plugin authors would WANT their plugins to comply and would make a point of doing so before a release.
    Thanks for keeping us safe, WP guys!
    E.

    [Reply]

    xxxevilgrinxxx (3 comments.) — 08/24/2008 @ 8:59 pm
29. 

    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.

    [