Page fragment caching is a must-have function for cache plugins like W3 Total Cache, it’s a shame that such functions didn’t get much attention.

W3 Total Cache answered the “How do I implement page fragment caching?” question in the Developers section in their plugin FAQ page:

First you need to define W3TC_DYNAMIC_SECURITY in your wp-config.php file.

define('W3TC_DYNAMIC_SECURITY', 'somesecurestring');

Edit your templates with the following syntax to ensure that dynamic features remain so. Replace W3TC_DYNAMIC_SECURITY with content of the constant or use echo to print constant:

Example 1:
<!-- mfunc W3TC_DYNAMIC_SECURITY any PHP code --><!-- /mfunc W3TC_DYNAMIC_SECURITY -->
Example 2:
<!-- mfunc W3TC_DYNAMIC_SECURITY -->any PHP code<!-- /mfunc W3TC_DYNAMIC_SECURITY -->
Example 3:
echo rand();
<!--/mfunc W3TC_DYNAMIC_SECURITY -->
Example 4:
<!-- mclude W3TC_DYNAMIC_SECURITY path/to/file.php --><!-- /mclude W3TC_DYNAMIC_SECURITY -->
Example 5:
<!-- mclude W3TC_DYNAMIC_SECURITY -->path/to/file.php<!-- /mclude W3TC_DYNAMIC_SECURITY -->
Be aware that WordPress functions will not be available.

The answer itself is pretty much clear except it forgot to mention a most important step: YOU NEED TO ADD ‘mfunc’ TO THE ‘Ignored comment stems’ SETTINGS.

Source: WooThemes http://www.lost-in-code.com/platforms/wordpress/w3tc-fragment-caching-mfunc/

Without this step you’ll waste 100 hours on testing the page fragment caching and never getting it worked. Thanks to WooThemes pointed it out and hope I can save someone else’s 100 hours.

Implementing Page Fragment Caching in W3 Total Cache


Setting Page Title Dynamically In AngularJS WordPress Theme

Changing the page title dynamically is an important feature in our AngularJS WordPress Theme. If you have checked some articles related to this topic, you might find it’s a bit hard to integrate those methods to our theme. There are two reasons:

  1. We just moved the ng-app="app" from html to #page div, that means the title element is beyond the scope of our app. Most of the tutorials use the $scope.title approach to change page title, unfortunately it won’t work with our theme.
  2. Most tutorials will predefine a title for each route, for example there are 3 files a.html, b.html and c.html, and their titles are like Page A, Page B and Page C. In such scenario it’s much easier to get and set the page title on $routeChangeSuccess event. But our case is a bit different that we’ll need to get a post from WP API first to know what the title is.

This post from stackoverflow gave me an idea to change the title with the global variable document. Here’s the snippet I use to change the page title dynamically (line 7, line 14).

Note that I use document.querySelector('title').innerHTML rather than document.title, so special characters like HTML entities won’t be decoded. You can get full project files from the GitHub repo.

If you have any question related to my AngularJS WordPress theme series, just leave a comment here, I’ll get back to you as soon as I can.


Making WordPress Admin Bar Work With AngularJS Theme

In my tutorials of AngularJS WordPress theme, I’ve always put ng-app="app" in html tag. Maybe I haven’t mentioned, but in fact, the ng-app="app" can go with any HTML tag in your page, as long as it makes sense. For example, it’s obvious the body tag should be the second best place to insert the ng-app="app" if we’d like to enable AngularJS on the whole page.

There is another topic Ryan reminded me few days ago, he noticed the admin bar can’t work with our AngularJS theme. It looked all right, but when clicked the links, the page wouldn’t go to admin panel, but stayed on the same page without content:

Admin Bar doesn't work with AngularJS

In this situation, we can’t see any errors in JavaScript console, that means there is nothing wrong in our code. So what’s the real problem?

You should realize now that with my hint in the first paragraph, it has to do with the position of ng-app. The ng-app is basically a way AgularJS declares that “this part of page belongs to me“. When we set the whole html to be manipulated by AngularJS, clicking any link on the page, AngularJS will check if the pattern of the URL matches a route, then display the template accordingly.

Since the URLs in the admin bar don’t match any of the routes, it starts acting weird.

So what can we do? We need to move the admin bar to somewhere not ruled by All Mighty AngularJS.

  1. If you use the project files from my previous tutorial, please add wp_footer(); to index.php first, and make sure there’s nothing like add_filter('show_admin_bar', '__return_false'); in the functions.php, or the admin bar won’t be displayed.
  2. Modify index.php to code below, so admin bar can get away from AngularJS:

Another thing to note is we should add a default route to our app for the best practice. We can do so by adding otherwise method at line 15, and please note that I changed the route of content page either, or the $routeProvider will never fall back to otherwise:

Now if a visitor tries to go some page doesn’t exists, the homepage will show.

Just download the full project files on GitHub (with bonus content that I will introduce in my next article – How To Dynamically Set the Page Title). While waiting for the next post, you can find more information about ngApp on the official AngularJS documentation.


Using Slug To Get Single Post In AngularJS WordPress Theme

In the first post of my AngularJS WordPress theme series, I set the post title to link to {{post.ID}} so I can get a single post with the default route in WP API: /posts/<id>.

Couple days ago Ryan asked me can we use slug instead of ID, and reminded me that in the original demo video (Eric Wolfe: Building a WordPress Theme Using AngularJS), Eric did use the slug rather than ID. At first I replied to him it’s because Eric used the JSON API not WP API (JSON REST API), by default the WP API can only get post by ID.

The answer was not so persuasive I thought it’s better to double checked. Luckily I found the right answer in Josh‘s article on Torquewe can get posts by slug with filter parameter.

So here are the snippets you’ll need to update, if you prefer to use slug in our project files (from my previous tutorials):

1. js/scripts.js

  • line 6: Change /:ID to /:slug
  • line 16: Change 'wp-json/posts/' + $routeParams.ID to 'wp-json/posts/?filter[name]=' + $routeParams.slug
  • line 17: With this approach, we’ll get an array of posts, so we need to change $scope.post to $scope.posts

2. partials/content.html

  • line1, line2: Change post to posts[0]

3. partials/main.html

  • line 5: Change {{post.ID}} to {{post.slug}}

You can get the full code from a branch of the project repo. I hope short posts like this can also help readers understand better about AngularJS and WordPress, especially how to accomplish a specific task. See you soon.

Plugin Development

Inserting Media Search Form Into Posts Or Templates

I’ve got lots of plugin ideas but don’t have much time on developing recently, due to I’m fascinated by AngularJS since last November and prepare to grow my freelancing business. Despite that I still try to take some time to update my plugins based on suggestions from users.

Today I just pushed the latest version of Media Search Enhanced to WP.org, the major updates are inspired by a comment left here last week. Basically Don requested if I can make the plugin work on the frontend, so website visitors can search for media by all fields (title, caption, alt text, filename and terms).

I found it interesting because I’ve considered to implement functions like that but not sure if it’s of use enough. According to Don’s comment, it will be a very good idea.

So I made a major change that moved all main functions from admin class to public class in my plugin, and create a shortcode mse-search-form to insert a media search form into posts or templates. The media search form is a default WordPress search form but customized:

  1. Add a hidden field to force it only to search for attachment post type.
  2. Add a class name mse-search-form to help if user would like to modify the form with CSS.
  3. Two custom filters in the form: mse_search_form_class to change the form class name, mse_search_form_placeholder to change the input placeholder.

For now the frontend media search form might not be that helpful that it just display all media as posts in search results page. You have to custom the page to make sense of it, so maybe I should improve it in the next release by adding a media search results page or creating a media search results shortcode.

Other comments on the WP.org support forum proposed to display the media search results but group them by post id, and search for meta values. These opinions are useful to some extend so I’ll keep in mind. Your feedback is always welcome. Let’s improve the media search workflow together!


Yesterday when I published my thoughts about Freelance Web Developers Market Research, it’s the first time I wrote a 2000-word article on my blog, I thought it was a good idea to add page links to divide it into two pages.

I knew Ryu (the theme I used for this blog) had styled the page links so it should work fine. But later I found the page links showed after three blocks I’ve added with plugins – share buttons, related posts and author box. My visitors might not know there was a second page of that post.

When looked into the code I found the developer used wp_link_pages() under the_content() in content.php, but the plugins I used hooked their code to the end of the_content filter, that’s why the page links would always be displayed after them.

Here are the snippets I added to the child theme of Ryu to solve my problem.

1. Remove the wp_link_pages() from content.php

2. Hook wp_link_pages() to the_content filter in functions.php

Now it works and I’m still amazed that such a beautiful, elegant theme is free on WP.org.

Move page links on top of share buttons in Ryu

Freelance Better

Things about the Freelance Web Developers Market Research

Last Christmas I started an online survey about why freelance web developers get hired. The survey was simple with only 3 main questions. It was for whom was hired as freelance web developers, or who had ever hired them. The 3 questions for these 2 groups were different:

  • Freelance web developers would be asked:
    • How do your clients find about you?
    • How do you spread the word about your brand and your work?
    • What do you wish you had known when you first started?
  • People who had ever hired freelance web developers would be asked:
    • Why did you hire a specific freelance web developer?
    • What issues or challenges led you to hire him / her?
    • What result did you expect when work with him / her?

Sounds interesting? Now let me tell you the behind-the-scenes story about why I started the survey, how I conducted it, and most importantly, what I’ve learned. Continue reading