Miscellenous WP 1.3 development notes/ideas

A list of things I’ve noted, provided, or want to inquire about to help contribute to WordPress v1.3 (or as ideas for future versions), roughly in ascending order from trivial to implement to complex.

1. readme.html has typo and still refers to v1.2
   • In the readme.html file in CVS, “Recommendations” is misspelled “Recomendations”
   • Also, v1.2 is referenced twice, whereas it should be updated to say 1.3
2. description for Hello Dolly plugin notes a now non-issue
   The description for the Hello Dolly plugin says it’ll show on “every page but the plugins page”, but that is no longer the case with v1.3
3. create wp-content/images/ and wp-content/cache/
   To reinforce to users and plugin developers that wp-content/ is the recommended location for such things as images and cache files, those directories should be pre-created.
4. use get_settings('blogfilename') instead of hardcoded index.php
   In wp-includes/functions.php (functions pingGeoURLs(), rewrite_rules()), there are hardcoded instances of index.php which should be replaced with get_settings(‘blogfilename’) to facilitate running WP from a file other than index.php
5. hide custom fields section in post edit page
   Matt expressed a desire to hide the custom field section in the post edit page because it’s unwieldy and not used often enough to always be used (paraphrased). I modified code from ScriptyGoddess‘s show/hide more plugin to allow showing/hiding the custom fields (and (see later) the hidden fields) section of the post edit page. I have a working demo of this that I hope to show Matt at some point.
6. patch balanceTags()
   in wp-includes/functions-formatting.php, the function balanceTags() has the potential to eat user text, improperly balance tags, and not balance tags. I examined the problems with the function and proposed a patch (to bug 0000053).
7. patch make_clickable()
   The latest CVS version has a quoting mismatch bug for auto-hyperlinked e-mail addresses (opens with a single-quote, closes with a double). The patch would take into account some of what Auto-hyperlink URLs does, though with some things in mind after having chatted with Matt in IRC.
8. don’t balanceTags for drafts
   Drafts, by their very nature, may be incomplete, both in terms of content and the (X)HTML. However, if the setting is set to enable balanceTags(), posts saved as drafts get their tags balanced (and if the current balanceTags() is left in place, there is a greater likelihood of user text getting eaten). The fix is to only balance tags for a ‘publish’. I started the patch for post.php, but got sidetracked. I should pick it up again soon.
9. abstract mail() usage into wp-mailer() function/class
   For those who can’t, don’t, or won’t use sendmail, it’d be nice to offer alternate mailing solution(s), namely sending mail directly to SMTP server. I actually have a plugin, wpPHPMailer, that utilizes the open source PHPMailer to achieve this. If integrated into the core, I’m sure the plugin itself would need some modification, options would need to be added to designate if sendmail should be used, or SMTP (and if the latter, the host, username, and password (if required)).
10. add hidden fields
    Hidden fields are pretty much custom fields, but with a layer of removal from the user. Custom fields are a powerful feature, and the mechanism can be put to good use by WordPress itself as well as plugins. However, users should have to take an extra step to view such fields. As is, plugin- or WordPress- created custom fields would be mixed in with user-created custom fields. Users may not understand how the field got there, and depending on the number of user and non-user created fields, the list could be a jumble. Visually, the hidden fields section should follow the custom field section, separately controlled via a “Show hidden fields” checkbox. To prevent inaccessibility of data, hidden fields would be listed and modifiable just like custom fields, though perhaps without the ability for the user to add hidden fields directly (not sure). As for coding implementation, perhaps an additional column in the wp_postmeta table, meta_type, with a value to indicate if meta field is custom or hidden. Existing meta functions could be extended to have a $type=0 argument.
11. feature: persistent custom fields
    Add a mechanism (checkbox next to custom fields?) that makes a custom field persistent, always appearing under each post (and always visible, even if the show/hide custom fields patch is applied). This would facilitate users who make frequent use of multiple custom fields for each post.