Archive for the ‘Feature Requests’ Category
Mandy has a great idea with having text box widgets be nameable inside of the WordPress widgets area. If you add a Title, yes, they get shown as “Text: My Ad”, but then that “My Ad” title also gets displayed to the user. That’s really not what you want.
Disclosure: Mandy contacted us at the WordPress HelpCenter about this idea, and I suggested that she post it on the Ideas Forum.
Related: As a “WordPress Professional” now, I expect I’ll blog here a bit more going forward.
As I look at the planned features for WP 2.7 as reported by Weblog Tools Collection, I’m having a few thoughts:
- I noted on the 27th that it made sense that WordPress would be hosting themes at wordpress.org/extend to allow for ease-of-upgrading, and it looks like a Theme Update API will help with that.
- Plugin management and overall WP upgrade management is improving. That’s a net win for everything WP-related, security most of all. [Same goes for theme.] Making users aware that software is due to be upgraded and making it easy for them to do so is what’s going to help solve WordPress’s reputation as a black-hat scammer’s favorite target.
- There’s still no love for an AJAX-ified TrackBack tool entry. It’s still “(Separate multiple URLs with spaces)”. Criminy.
- A side benefit of hosting the plugins on wordpress.org/extend is that the WP folks can see which plugins are truly getting the most use. It looks like things like comment threading, XML sitemap generation, and comment subscription are going to make their way into the core codebase. Now, there is an argument to be made that leaving these things to plugins is just fine—that WP’s core should have the absolute minimum number of functions involved, and that anything but basic functionality should be left to plugins. There are many arguments to be made for this philosophy pro and con, but I think that, at the end of the day, WordPress should bring in the most popular plugins into the codebase. Why? If it’s terribly popular, it’ll be seen as quasi-official, and anything that’s gotten that level of praise in the community needs to have a more stringent security review than relying on a third-party developer. Note: This is not a slam on 3rd party devs at all. It’s actually a praise—if you’ve gotten that popular, it’s a good thing. Now, one can argue whether WP’s security reviews and patches are stringent or swift enough [and the answer to that seems to be that there will never be a time when everyone is satisfied by either], but if WP brings it under the umbrella, they’re saying, “This is mission critical.” Also, it reduces user/administrator workload in keeping plugins up-to-date.
- All that said, it surprises me that Akismet is still a plugin and not a part of the core for this very reason, and I say that as an avid fan of Spam Karma, a financial contributor to same, and someone who considered, briefly, helping the GPL project along from a management / usability review perspective. [That’s before I told myself that I didn’t want to make the time for it.]
As WordPress progresses towards full-maturity—right now, it’s out of college and in its first job, making lots of dough and acquiring lots of stuff—these are all good things. I’m still very much a happy WordPress supporter. 🙂
I’ve found BlogSecurity’s WordPress Scanner to be invaluable for me; I’ve recently brought a bunch of installs up to current, but I hadn’t considered the vulnerabilities in XSS attacks on templates. But now that I know that those have holes, too, I can patch them up.
Go give WordPress Scanner a shot: all you’ll need to do to let it run is to put
<!-- wpscanner --> somewhere in your template. I’d suggest putting it in the Header, where any page that WordPress Scanner comes across would have access to the statement. That way, all pages can be scanned for vulnerabilities. Just be sure to remove it after the scan is over so some black hat can’t use it against you! 😉
It would be awesome if WordPress would include a post-upgrade scanner into the mix, checking your theme for possible holes. Upgrading WP only fixes the core files—any template you’ve used other than the default isn’t going to get fixed, and it could have a hole.
As Joe Gregorio notes, WordPress was supposed to support Atom 1.0 starting with the 1.6 milestone [which, as I recall, never happened and became 2.0]. Mark Pilgrim is frustrated, too. So am I, but this should be a surprise to exactly no one.
But being one to work within the system … there’s the new Ideas forum, and well, there’s a topic to support Atom 1.0 support in the next release. I’ve already chimed in. Go rate it up. If we all rate it up, perhaps it will become a priority. [It should be, anyway; WP is shipping to a deprecated version of a specification, something really outside the main WP ethos.]
I complained nine months ago about the lack of Atom 1.0 support in WordPress. It’s still a bit stunning to me that, a few releases later, WP still doesn’t have that support. But today, Sam Ruby pointed to Benjamin Smedburg’s plugin that generates Atom 1.0 output for WordPress. Huzzah!
I’ve gotta say that I find ticket 2972 to be wonderfully right-headed:
Currently, the most recent page (in any of the archives — dated, categorized) is page number 0. When clicking on Next Page, the url shows it being paged=1, thus page number 1. Going back even further, the page numbers increase.
However, when new posts are added, all the content in the pages shift with it.
In my opinion, it would be better if the oldest posts would be on page 1. This way, if new posts are added, consequently new pages are added. AND the content of the pages stay the same.
It’s all about future-proofing, and that’s a very, very good thing.
As I’ve been using WP 2.0, the thing I find myself most wishing for is some AJAX love for TrackBack. Yes, many argue that TB is broken, and while I understand why, some of us are still true believers. Anyway, what is with this space-separated nonsense at this point? Seems like this would be a key place to dump an URI, hit a button, and have another form block open for the next one. It would be even cooler if there were a way for WP to check for the validity of the TrackBack URI upon a Save and Continue Editing run.