Photon is a great free image CDN that you can use with any self-hosted WordPress install via Automattic’s Jetpack suite of plugins. Photon uses wordpress.com’s infrastructure to host your site’s images on one of the fastest CDN globally.
I highly recommend enabling it on every WordPress install. If your site is on cheap shared hosting, it will dramatically improve page load times. If you’re hosting a huge news site, it’ll save you loads of money.
By default, Photon automagically serves any images embedded in or attached to a WordPress post or page. Including feature images, galleries, third-party sliders. Due to the nature of WordPress hooks and filters, it’s not possible for photon to grab images stored in post meta fields, or any images that are part of theme template files.
I’ve written a gist that exposes Photon’s CDN wrapper as a simple function you can call in templates:
Today I relaunched my WordPress plugin (RetroPosts) with the more descriptive title: “Historian” and a pretty major feature, a sidebar widget!
Historian is a plugin that gives you a glimpse into the past by surfacing your blog post’s from this week in history. I’ve been blogging on ohryan.ca for 7 years and every time I look at the plugin, I am reminded about a cool thing from the past. It’s really interesting to see of far the internet has come since I started this blog.
For example, I couldn’t believe how terribad the first version of Instapaper was? I found this by reading one of my old posts. Based on the techcrunch post this was considered great app design back in 2008. Unbelievable.
When I originally came up with the idea for Historian, I had thought it would just be a useful way to gain some inspiration from the past or follow up on a topic I hadn’t covered in a while.
In reality, I think it could be really cool to let your visitors see what you’ve written in the past. I think it can add some credibility to your blog if you once were a more prolific blogger than you are today.
Above is an eight and a half minute video from the developer of the Avada WordPress theme. The video demonstrates how to configure pages within the theme using shortcodes. Jump around the video a bit to get feel for the “workflow.”
WordPress’ shortcode API is designed to be simple and power. It allows WordPress theme and plugin developers enable short snippets to text, for embedding dynamic content. For example, [gallery id="123" size="medium"] to display WordPress native galleries.
Somewhere in the past few years, commercial theme developers have started infecting theme marketplaces with these crazy “shortcode generators.” It turns out that (intentionally or otherwise), WordPress’ shortcode generate is powerful enough to enable very HTML-like features. Theme developers have been using this to create their own psuedo-HTML…
IT HAS TO STOP
Once you set up a page with 10kb of “shortcodes” you’re defeating the purpose. Here are a couple of examples for the Avada documentation Homepage 1, Homepage 18, etc.
I think I understand the problem that these theme developers are trying to solve. They’re trying to make complex layouts editable via the WordPress admin tool. In theory shortcode generators simplify this problem for non-developers and regular users. Unfortunately there are many many problems with this type of shortcode abuse.
It does not work for end-users.
WordPress’ WYSIWYG editor is designed to behave like a Windows Office application, something people are familiar with. It’d designed for writing and formatting text. Not editing psuedo-HTML. I absolutely guarantee someone who’s content creation experience revolves consists of Microsoft Word, or other blogging platforms, will be scared shitless by a shortcode generator. They won’t know what to do.
It does not work for designers.
Shortcode generators aren’t visual or interactive enough for most graphic designers I know. It’s too much work. They won’t use it.
It does not for developers.
Any front-end developer worth their salt will puke their guts upon seeing the massive pikes of garbage these shortcode generators spew. They might use it, but they won’t like it.
It interferes the visual editor. If you accidentally bold a shortcode, add a space or linebreak somewhere you shouldn’t, etc. you’re hooped. The shortcode breaks and your entire page layout is f’d.
It is not maintainable. If you need to update the copy it can be nearly impossible to find. I usually end up doing a cmd+f and that feels so wrong. Added page content can be even harder. Since these shortcodes end up in unformatted and unstructured blocks of text, they are actually harder to edit and update than a static HTML file.
Solutions?
As a developer there I have a few different ideas on how to solve the problem.
Ignore WordPress’ WYSIWYG editor. Most of the time, the pages that these types of themes end up generating are pretty looking sales pages or other static content. When the content is static, or virtually there’s no need to give your the end-user access to the copy. Sure, you may have sold your client on WordPress as a great solution to update your website and you my feel the pressure to give them access to absolutely everything from the WordPress admin. But giving them a pile of shortcode shit to work with is worse than not given them access to any content.
Use custom meta boxes.
I’ve successfully developed themes where you place the content in custom meta boxes. The open source ‘Custom Metaboxes and Fields for WordPress‘ framework allows developers to add all types of content to WordPress’ custom meta boxes, even WYSWYG editors. This allows you as the developer to control exactly where page content appears in the HTML, while giving your client the ability to edit the content on a whim.
One of the most annoying things about setting up a dev environment for an existing WordPress site is syncing the content. Pulling down the database is trivial, even a large site will have a relatively small database dump. I often use the WordPress Duplicator plugin. But a site with years of photos and other uploads can have gigabits of files and it’s not really ideal to have to pull those all down from the site.
So for any file requested within wp-content/uploads/, that does not exist, it will serve the image from http://yourlivesite.com.
The only minor downside with this approach is the lack of offline. If you lose access to an internet connection, you lose access to the live site files, obviously.
