randybrown

Good product by good people — but I get the impression that the internal code of the tool is hands off except for the vetted developers.

“Too many cooks…”
Limiting the development team is one of the best ways to ensure there is consistency in the underlying coding standards of a project. Having consistency is one of the ways to limit bugs and feature creep.
Back to the issue of “plugin approval” – here is where additional development, outside development by those who want to add value and features to WP which are not present in the core code, comes in.
From my perspective, I’d rather have a solid, standards compliant core set of weblog tools available, along with the extensibility of a plugin system. I’d rather modifications to the core weblog tools come in the form of well designed plugins, rather than “hacks” to the core.
The former will produce a much more reliable system than the latter. Plus, I can install plugins to give me the features I want, and leave out the plugins that contain features I don’t need.
Good discussion.

The main software doesn’t have much documentation so why would it be necessary for add-on hacks?

I guess it’s a matter of perspective. Documentation adds to the level of professionalism of a product. I see here that there’s already concern/interest in creating more complete documentation for the weblog software itself. So, now that the plugin mechanism is in place in 1.2 (I’m not talking abut “hacks” – that’s has been discussed elsewhere) it seems a perfect time to think about how to better provide plugins for WP’s userbase, existing and new. WP now has a “plugin” interface, so it has moved out of the “hack” mode, it seems to me, and into the rhelm of providing a more formal interface with which to extend WP’s basic capabilities. That’s why this is a great time to consider how WP will handle the plugins.
As to whether or not it’s the user’s responsibility to fix bugs, of course I disagree with this. I understand that WP is open source, but I don’t think that means “unsupported” or “buggy until you fix it on your own”. That’s just silly. The user community will of course fix bugs and offer improvements to the code; that’s open source. But requiring a user to fix bugs is not the making of great software.
Again, I think it’s a matter of perspective. From my perspective, WP has the opportuity to go down a road that many other weblog packages have not. That of course is not up to me; I am merely making a suggestion that WP consider how it approaches some aspects of how it handles users.
<rb>

Plugins could be checked and approved by a fairly simple process:

• Does it have documentation which explains it purpose, its use, and its installation /configuration process?
• Does the plugin produce web standards-compliant XHTML and CSS (if used)?
• Does plugin follow do what it is designed to do reliably?

I suggest these guidelines and the “approval” process as I have seen other weblog software suffer from “hacks” that are poorly coded, documented, etc. Users complain, and the complaints then get directed back to the weblog software.
It’s important to keep in mind that not all weblog users are coders, hence the benefit of well designed and documented plugins.
Probably a good idea to identify plugins that are excellent, and also recognize – through not gaining approval status – those which are not.
<rb>

Great. This could be the solution I am looking for in making the switch from NucleusCMS.
<rb>

Is there a way to show the various categories from the Links Manager? If so, you could set of a category specifically for this, then link to the book reviews on bn.com or amazon.com, etc.
<rb>

Thanks. I made the mod to options-writing.php and all is well. Will look for next nightly build.

I’m running the 4/15 nightly build. Unfortunately, I don’t understand how to use CVS, so will have to wait until someone posts a archive of the latest to the nightly build area here.

I get a similar error. I’ve looked at the wp-mail.php code, and it looks as though the first line of the email message needs to contain the username and password for the user you want to be able to post the email to the blog. I played around with that with the debug turned on, so I could see what was going on. the format of the first line of the email message needs to be –
username:password
But, even with wp-mail.php properly getting this, it still is not working correctly. Obvious: some vars are not being passed/set correctly.
If I knew a little more about WP I might be able to help track the problem down, but I’m quite new to this software.
Suggestion: could an option by included in admin that would allow us to choose a user, rather than including that info in the email message? For many of us, the user will be the admin account, and it’s probably a security risk to pass the admin password through POP3.
<rb>