It’s been a long time since my last post here. In the meanwhile, I’ve sharpened my WordPress kung fu significantly. I consider myself a pro-bono developer for a not for profit website which uses WordPress as CMS.
I dove into the WordPress code and wrote a couple thousand lines of code that plug into WordPress making heavy use of post and comment metadata to do a number of automated tasks like email reminders, tweets/retweets, customized comment and post notification emails, blast emails, custom post types, front end ajax stuff, etc. I generally eschew plugins as I generally have the capability to construct the customized code I need except in the cases where it’s just dumb easy to use a plugin like backing up the database tables, controlling wp-crons, etc. So, just as I have everything just the way I want it, here comes Gutenberg and “progress.”
I go back to the Handbook periodically and hope this JS React stuff starts to stick with me somehow like PHP did. It will eventually but not yet.
What’s bothering me most is that a lot of the metadata input I had built into my posts and custom post types hooked into actions/filters that are now non-functional. I could live with deprecated actions but there’s a bunch of stuff that just doesn’t fire anymore with Gutenberg running.
I’m hoping all my development work isn’t completely lost when I move to Gutenberg. I’m not sure I’m ready to sink the time required to fully port my work to Gutenberg. I’m not a reactionary by any means, but it’s going to take me a long time, if ever, to move to Gutenberg.
I was reading about contact forms at wpengineer and the code included the wp_enqueue_script call right in the template before the get_header() call. Brilliant! I had never read that about that technique. You don’t have to write conditional statements nor hook in within the functions.php file. This is especially handy if you use a premium theme. Premium themes usually have a functions.php file that includes a huge caveat not to modify it (for a lot of good reasons). An even better benefit to modifying the template is as your theme is updated, you don’t have to worry about carrying over custom edits.
I’ve been using EventCalendar3 for a couple of years. It’s a great plugin and version 3.1.4 still plays nice with WordPress 2.9.x. However, I was rolling out a new website with WordPress as CMS with a requirement for a Big Calendar. A couple of EC3 users had built big calendar capability into the development branch. The last beta version (EC3.2 beta 2) had big calendar functionality built in so I installed it. After I made the move to WordPress 2.9, everything seemed to be working fine until I realized my comments feed was returning a 404 all of a sudden. Comments on posts were feeding properly as were category based feeds and the site feed. So, I went through all the usual troubleshooting (check the wordpress.org forums and deactivate plugins). Turns out EC3.2 beta 2 was the culprit. When I deactivated it, my comments feed started working again.
I’ve spent a fair share of time going through the EC3 code over the past couple of years and couldn’t figure out what EC3 and comments had to do with each other. EC3 does highjack some feeds and futz with canonical redirects but everything I saw in the code seemed benign. I commented out some of the redirect functions with no luck. On my other blog with E3.1.4, my comments feed was fine and the plugin is still solid despite its apparent abandonment. Odd. After a couple of hours of troubleshooting, I packed it in.
Fortunately, I hit gold on my first stop through the WordPress plugin repository with Kieran’s excellent calendar plugin. It’s a no nonsense big calendar with two useful template tags to generate lists of events. While similar to EC3 in that it uses a separate table to store event data, it differs in that you add the events using a backend form rather than the posting method EC3 uses. You can link the event on the calendar to a blog posting (or any other url) which is a nice touch as well. Kieran’s plugin also seems pretty bulletproof as WordPress evolves.
It’s sad when a plugin withers away but plugin authors are very special people who give without compensation (for the most part) and are swamped with support requests from all kinds of folks who should have RTFM. When or if EC3.1.4 finally breaks, there’s an alternative.
I’ve been testing out EventCalendar ver 3.2 beta 2 with WordPress version 2.9 RC-1 for the last couple of hours. Everything I’ve tested/used seems to be working normally without throwing any errors. I haven’t tested every feature but the basic stuff is working ok on my local installation. php 5.2.11, mysql 5.1.41, apache/2.2.13. My setting is to Keep Events Separate. I did not test ‘Events are Normal Posts.’
- Add/delete event, including calendar popup.
- Calendar and Upcoming events widgets.
- js calendar month scrolling
- tooltips popups.
- proper linking to archive templates (monthly, daily).
- setting ec3 options in the admin back end.
What I didn’t test:
- calendar feeds via ics.
- complex ec3 queries.
Overall, I’m comfortable with upgrading WordPress and keeping my essential Event Calendar functionality. Version 3.1.4 seems to be working just fine with WordPress 2.9 as well. As always, caveat emptor.
Updated 6 Jan 10
Looks like EC3.2 beta2 broke my comments feed. I have no idea why. I took it down. No problem with EC3.1.4.
I’m no pro but I’ve been knocking around on my self hosted WP installation for a couple of years now. I can take apart the pieces of a theme, re-engineer existing CSS, bang out php and other stuff but I’m not a graphic artist nor a designer. On my self hosted install, I use a great, free theme (Web 2.0) which is now unsupported and highly tweaked for my use. When I was asked to help another volunteer based organization retool their web site, I thought of using WordPress as a CMS because I didn’t want to be the webmaster in the traditional sense with workflow going through me. Since I had a budget, I decided to use a premium theme, specifically The Station from WooThemes to get up and running quickly.
The premium theme market for WordPress seems to grow by the day. I’m not sure how I wound up with WooThemes but I’m happy I did. When you’re thinking about using or choosing a premium theme, here are a couple of items to consider:
- You are going to have to tinker with the theme files. If you think a premium theme will be 100% ready to go for your use, you’re mistaken. You’ll have to know some basic WordPress template and conditional tags to get your site just right.
- Consider using a vendor with a sizable portfolio of themes that use a common framework. That way if WordPress makes some structural changes, the vendor will make the their theme framework adapt to new WordPress features quickly.
- You will have to create template files if you use WordPress as a CMS. When selecting a premium theme, make sure the theme has multiple format templates so if you want a full width page (important in a CMS), you don’t have to create it from scratch.
- In many cases, you don’t want to make too many modifications to the theme’s functions.php file. When the theme updates, you could lose your mods if you didn’t use good practices making the changes. Look for a theme vendor who publishes recommended practices for making modifications. That’s good support.
Remember, when you buy a theme, you’re not just buying the creativity of the theme designer, you’re buying support. Make sure you understand what kind of support will be provided before you buy. So far, I’m very happy with WooThemes. Their support is excellent (via forums) and they’ve got a nice array of FAQs. Their code is formatted very well with extensive commenting. Makes tweaks and mods very simple.
As if I don’t have enough to do, I’m going to get a site up and running using WordPress as a CMS. I’ll probably have a little budget to do it so if anyone can recommend a CMS style theme (premium is ok), I’d appreciate it. I’ve had my blog theme running for so long and it’s so customized, I haven’t shopped for a theme in a long while. Plus my existing blog theme is not set up for CMS.
By the way, the site is not e-commerce but I will need advertisement space on the front page. As always, recommendations and comments are truly appreciated.
The WordPress 2.7 core has a setting to close comments for posts which exceed a user specified aging. Unfortunately, the core doesn’t differentiate between posts and pages. Since I need additional control, I use this wonderful plugin.
Given a choice, I would prefer if the plugin would filter the comment_status page when the post is called and change its value based on aging. This functionality would prevent having to send scheduled update queries to the posts table. I believe the core functionality works this way.
Update Feb 24, 2009 – I decided to have a go at making a theme function that would mimic the core’s behavior of closing the old posts on the fly without additional queries while preserving comments on pages. It was pretty simple. You have to remove the filter (‘the_posts’, ‘_close_comments_for_old_posts’ ), copy the
function _close_comments_for_old_posts from /wp-includes/comment.php, modify it to do an is_page() check, rename your new function and then add the new filter (‘the_posts,’your_function_name’) after you’ve defined it.
Ajay’s plugin will still allow you to keep specific posts open so there’s more functionality than what I need so my solution isn’t a replacement.