I got a response from the WordPress Plugin Directory today. Positive! They approved the new plugin’s home so I officialy let the plugin go public this morning. Of course I set up a page on my blog with the complete description, screenshots, feedback section (feature requests are welcome). Check it out – Technical Support for WordPress!
Thank you for your support and voting at WordPress.org ;)
So, you’re a freelancer and you make WordPress powered websites for your clients, cool. Now how many times have you experienced them calling, emailing, texting, tweeting you asking for a core upgrade, plugin upgrade, theme fix or whatever? Well I’ve been experiencing that quite a lot, and that’s a reason to charge an extra monthly fee for support. And with this plugin …
Yeah, with this plugin you’ll get rid of the annoying phonecalls and tweets. Technical Support for WordPress (formely called Bug Reporting for WordPress) adds a dashboard widget to the WordPress admin panel, where your clients could file a support ticket in only a few clicks! Pick a topic, write a title, describe the issue, send. Voila! You will receive the filed report by e-mail, well formatted and with all the necessary details. You can then take action, and finally reply to the e-mail when everything’s done.
This is one side of it. The second side is that the plugin is totally customizable, the subject and message format are powered by short tags, the topic list is customizable, and of course the company (provider) name and email address. This means that you can include a certain tag, keyword or whatever to the subject line, say “#CompanyName” then filter that in Gmail or whatever, and make different clients go to different folders. There, no more junk in your Inbox!
Okay there’s a second side, this means that there should be a third. What about branding? The plugin permits you to have a provider name, provider URL and a provider logo! Which will be displayed in your clients’ dashboards and will link directly to your website. That way, your clients will keep you in mind, 24/7! Ok, kidding, but it’s really good for branding..
Now, I know you already want this and can’t wait to download it, but hey, the request hasn’t been approved by the WordPress.org Plugin Directory yet, so as soon as it does, we’ll go live. Meanwhile take a look at these screenshots:
Looking forward to your comments, feature requests, etc ;)
There are tonnes of good plugins for displaying contact forms on your WordPress blog, even a simple comment form without displaying the comments would do just fine, but let’s speak about one called Contact Form 7 written by Takayuki Miyoshi. I don’t think there’s a reason behind the number 7, perhaps it meant the year 2007, when Takayuki published the first version of his plugin.
First of all I’d like to note that he plugin is very well written, it’s very, and I mean VERY flexible, and only due to its flexibility we’re allowed to extend its functionaltiy. Of course Takayuki’s probably missed some filters and hooks that other plugin and theme developers would love to see, but the modules directory is good enough, despiting the fact that it’ll probably be erased and rewritten after an ongoing plugin update.
Now, suppose you have designed a placed a contact form in your sidebar as a widget, using the Contact Form 7 shortcode. It’s got all the necessary fields, AJAX powered form, Akismet spam check & so on. But we’re missing something. Contact Form 7 is located in your sidebar, which means that you’re displaying it on most (if not all) of your posts and pages. Now when somebody writes a message via your contact form, you’re left guessing which page the visitor was viewing while typing.
This may be crucial in e-commerce situations, say you’re selling books from your blog, and a visitor contacts you to ask “who’s the publisher of this book?” or “how many pages does this book have?”. So you received an e-mail and you have no idea which book is being mentioned. You’re lucky if you only work with one publisher, or all your books are 100 pages long ;)
Anyways, let’s create a new file in the modules folder of the plugin, and call it sourceurl.php:
1 2 3 4 5 6 7 8 9 10 11 12 | wpcf7_add_shortcode('sourceurl', 'wpcf7_sourceurl_shortcode_handler', true); function wpcf7_sourceurl_shortcode_handler($tag) { if (!is_array($tag)) return ''; $name = $tag['name']; if (empty($name)) return ''; $html = '<input type="hidden" name="' . $name . '" value="http://' . $_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"] . '" />'; return $html; } |
This is very easy to understand once you’ve read (and understood) what’s written in the other modules. Try to take a look at text.php for a while, it includes the code for both text and e-mail fields. I copied some of the code for the text fields, simplified it a little and removed the validation process (why validate our own URL?), and voila, 12 lines of code ;)
Save the file and go to your Contact Form 7 settings in your WordPress admin panel. Select the contact form you’d like to add source URL to and in the part where it says “Form” add the new short code (sourceurl) and give it a name (thesource):
1 | [sourceurl thesource] |
Now you can use “thesource” in your Mail part of the contact form settings, say:
1 | Source URL: <a href="[thesource]">[thesource]</a><br /> |
Then look for the new Source URL in your e-mail ;) So if you’ve used more than one contact form on several different pages, just to distinguish them in your emails, you can merge them into one now. You can use a similar way to add other interesting data to your e-mails such as, say the user’s IP address for instance, browser capabilities, etc.
Yup, WordPress 2.9 is finally out and I’ve seen a lot of people upgrade immediately – sweet thing to do, I did so too and hadn’t had any problems here (I’m not using too much plugins), then I switched over to the 3.0 branch, all good! The semi-square buttons in the admin interface are fixed by the way ;) Anyways, this post is not about my blog, but about something I’m working on locally in the intranet of a company. And here’s a quick reminder: do not upgrade the running instance before you checked everything on a duplicate testing one, especially if a bunch of plugins there are handwritten ;)
A Handwritten WordPress Plugin is a huge set of files, with hundreds of duplicate lines of code and tonnes of commented code. The MVC/MVP models are usually transformed into the AIO (All-In-One) model. The only version control systems used are the “Copy & Paste” and “Undo & Redo”. The Core Upgrade process does not involve reading the changelog, backing up, etc.
Okay this is not a very smart thing to do, but sometimes you just need to, especially when you’re in a hurry (duh!). I’m not going to go in detail about the plugins, because you wouldn’t understand it anyway (no offence, I don’t understand most of it either), but let’s just say that I was using the Post Tags interface that you see in your “Edit Posts” admin interface. The sweet little box where you can type some tags or choose from the most used ones. All I did was copy the HTML contents of that little box onto my page, and it used to work (in 2.7 and 2.8), but as soon as I upgraded to 2.9, bang! It suddenly stopped. The javascript bindings were gone!
I figured out that the bindings were all made in the post.js so I took a look at the diff between 2.8 and 2.9 – completely different. The major change was the jQuery selector from span#ajaxtag to div.ajaxtag (line 99 in post.dev.js) which prevented all the other bindings. A few more ids have changed to include the tax name, and some other minor changes which I didn’t figure out yet. Although what’s the point in figuring it out? Wait until 3.0 is released and rewrite the plugin again, meh!
I did a lot of thinking here. This was not the only interface that broke, and rewriting everything on every core upgrade would be pretty difficult. People talk a lot about WordPress upgrades, plugins compatibility, etc. But most of the time they refer to plugins developed by other people, which sooner or later will get an upgrade. So waiting for a few weeks before launching the core upgrade generally does the job. But what if it’s a completely different page with a completely customized admin interface?
I worked a lot with WordPress metaboxes a few weeks before the upgrade and today I figured out that the best and easiest way of building WordPress admin interfaces would be, that’s right, metaboxing. The standard components used in the edit posts/pages interface (tags, publishing, categories, custom fields, etc) are simple metaboxes. So why copy HTML if you could simply use the predefined ones? And when a change is on its way, you’d sleep tight. Unless of course you’re interacting with the standard components from your customized ones, which involves using certain selectors for ids and classes. In that case you’ll just have to read the changelog, tickets (over 500 for WordPress 2.9) and of course code diffs.
Creating your own custom metaboxes is not as difficult as it is at first sight (yet I still haven’t figured out how to save their positions via AJAX, but I will). You will get the hang of it after your third or fourth metabox ;)
P.S. Have you noticed the new post thumbnails here? They used to be wide images, now they’re h2 text and small thumbnail. I love WordPress shortcodes ;)
A few days ago Frederick Townes, author of the W3 Total Cache for WordPress has released an update to this wonderful plugin, and yes, it now fully supports Amazon S3 and CloudFront as the Content Delivery Network! This is a major one for me as I manually upload most of the static assets to my CloudFront account which may take quite a lot of time. The W3 Total Cache plugin does that for you in seconds! Post attachments, images, javascript, css.. All those could go to CloudFront in just 4 clicks. Frederick also mentioned that the upcoming update will also be surprising, which keeps me wondering.
I also tried out the other options for page and database caching. A few tests showed up that memcache is faster than APC, so that’s where I stopped at database caching. Page caching was switched to enhanced, which I believe is a new option. The site performance graph at Google Webmaster Tools shows pretty good performance for Novermber and December (very close to 1.5 seconds) although the overall average is still up at 3.5 seconds, which in terms of Google is slower than 59% of sites. This is probably caused by the force majeures in September and October. Page load time peaked at over 7 seconds there.
One more funny fact about Google’s Site performance and Page Speed tools is the “Minimize DNS lookups” section, which most of the time shows up a single entry:
The domains of the following URLs only serve one resource each. If possible, avoid the extra DNS lookups by serving these resources from existing domains: http://www.google-analytics.com/ga.js
Interesting. Perhaps I should copy that javascript file and serve it from my CDN, I wonder if that will work. Oh and then I’ll be missing all the nifty updates to Google Analytics, like the most recent one called Asynchronous Tracking – very neat by the way!
