I was working on a website this week where I wanted to use WordPress so the client could benefit from its CMS and blogging capabilites, but also wanted to use a PHP framework to handle some custom programming. Compared to WordPress, almost any PHP framework is going to be easier to do custom programming with. But what about routing? How will the website know what to route to the framework, and what to route to WordPress?
If you want to rename the WordPress default post type, I wrote a super simple plugin to handle this. Before installing and activating the plugin, all you need to do is change the value of the $singular and $plural class properties. Use whatever you want. For instance, if you want “Posts” to be “News”, you would change both values to “News”. If you want “Posts” to be “Articles”, then I’ve already done that for you in the sample code below.
Downloading WordPress, unzipping it on your computer, then using FTP to send it to your website hosting environment is slow. This whole process, even with a very fast internet connection, can take 10 minutes. If you’ve got a slow internet connection, you might as well go to lunch.
WordPress makes it relatively easy to search through post content before it’s too late to use its wp_enqueue_script or wp_enqueue_style functions. Comments on the other hand don’t have an action hook that is called early enough.
I’ve done WordPress domain changes a few times. Most of the time it’s just a way of importing a production installation to my development environment, but I’ve done it a couple times on production environments. To be clear, I’ve never had a problem with it. There’s a first time for everything, right?
WordPress documentation regarding the subject:
When I set up this blog on the production server, I thought I was going to be able to eliminate some of the database bloat by removing all of the default themes and installing my custom theme before running the install. My theme has some code in the functions.php file that removes all of the admin dashboard feeds. It didn’t work. WordPress expects there to be an activated theme, and isn’t smart enough to use the only one there is in the themes directory. I probably could have accessed the database and changed the theme before doing the install, but I’m not sure I would have achieved what I set out to do.
In a blog post I wrote last month, “Rebuilding Image Tags When Adding Media”, I discussed a technique that builds image tags instead of removing attributes that are undesirable. As it becomes more popular, a lot of web designers are going to want to incorporate Responsive Web Design, and removing an image’s width or height attribute may be essential.
There was a problem with my proposed code. If the image was sent to the editor inside an anchor or had a caption, and if using the visual editor, the caption would disappear on save, or the undesired attributes would not be removed. Unpredictable behavior would also occur when switching between the visual and text tabs. This is really not acceptable for the majority of WordPress users, so I thought I better try to figure out a better way to handle removing the width and height attributes of images.