I run a website, wycliffe.me, for redirecting traffic (URL redirector). But I need it to have a CRM sort of component to it. So I added some custom fields to the Posts using Just Custom Fields. (I am using Posts, but I could just as well use a custom post type Custom Post Type UI.) But now I want a summary of some of those fields in a special panel on the back-end. So I have collected some links to read and start hacking.
First I need to create an options page in the admin area: http://buildinternet.com/2010/01/create-custom-option-panels-with-wordpress-2-9/.
Next I need a way to collect the data. So I look for a plugin which can search my database and return fields…. sorta like views for Drupal. And wala there is such a plugin: Query Wrangler. (Query Posts might be another option, but I did not try it.) However, this plugin is not powerful enough. I can not search all the fields created by my other plugins, only my custom fields and content types. More power would be ideal.
I like my URLs to be semantic, it helps with SEO and it helps users to know what a page is about based on the URL. Today I was looking over one of my old posts and found that the TM is added to the URL. In the admin UI the title looks like this:
Title in the Admin UI
Notice that I have used the & in html in the tiled. This is stripped out by the automatic URL generating engine of WordPress. However the ™ as a unicode character is not removed. Some languages with non-roman scripts need Unicode in the titles, so not all unicode characters should be disallowed in the titles. In fact, all Unicode characters should be allowed in the title field. Sometimes unicode in the URL is allowed, however it is not always best practice (unicode above the ASCII range). I in this case it should not be allowed by WordPress. I have my permalink settings set to custom. I do /%year%/%postname%/.
However, when a unicode character is put into the postname, it is not necessarily striped out. My contention is that some characters should be, or that more characters should be. The problem for users is that the unicode character gets processed to the browser’s URL bar and looks like the following: https://hugh.thejourneyler.org/2010/selected-works™-bepress/ .
However, when the user selects the url to copy it they do not get a URL which is paste able the same as when they saw it in the URL bar, they get something like the following: https://hugh.thejourneyler.org/2010/selected-works%E2%84%A2-bepress/ .
One solution might be for authors to use the following HTML markup in the title:
But this is not user intuitive or presenting a “thoughtless process for end users/authors”.