A former client contacted me this week because they were thinking about switching platforms for their ecommerce store. The site had originally been built on WooCommerce but they were now considering a switch to Shopify. The main issue is they didn’t want to have to rely on a developer for site updates and wanted a solution they could more easily manage themselves.
To answer their questions, I signed up for a Shopify account and then went through the technical and business requirements one by one. If you’re trying to decide between Shopify and WooCommerce, hopefully some of these notes are useful. Continue reading →
Tracking anonymous visitors across multiple domains is difficult because cookies can’t be shared across domains. One way around this is to use an iframe to set the cookie, which works well in Chrome, Firefox, and Edge. However, Safari prevents a challenge because it prevents third-party cookies from being set.
I haven’t found a solution for the Safari issue yet, but thought I’d share the method I’ve worked out for cross domain tracking with Mixpanel for the remaining browsers.
For the example, I’ll use domains a A.com and B.com. A.com is the primary website and B.com is a marketing website that refers traffic to A.com.
On domain A.com you’ll need to set up an URL that loads the tracking code when it’s called inside of an iframe. We can pass tracking data from B.com to the iframe using a query string, and an efficient method for passing that data is by base64 encoding an JSON object. Continue reading →
We use Mixpanel at Cratejoy to track a lot of user interactions across the sites. However, there was a lot of profile data we were storing (and paying for) that we weren’t actually doing much with. So, I decided to see if it was possible to back up this data locally, create re-import files (in case we ever needed it again), and then delete in bulk.
I’ve been updating several of my themes to support the new custom logo feature that is being introduced in WordPress 4.5 (read about it here).
Most of my themes already had a logo option, so part of adding support for this new feature has been to build an update script to migrate the previously saved value (generally saved to the theme mod “logo”), to the new theme mod “custom_logo”.
I assume a lot of other theme authors will also be doing this, so I’m sharing my update code in case it can save someone a few minutes. Continue reading →
I’ve started using DeployBot to manage a lot of my code deployments. It works great if you develop custom themes for clients and keep your repositories in hosted version control (like GitHub or BitBucket).
I generally work in a “staging” branch (when I’m working solo), which auto-deploys to the staging environment. I trigger deploys to production with commit messages to the master branch, i.e. “Version 1.2.2 [deploy production]”.
One really nice feature Deploybot added recently is the ability to run build tasks on a cloud server before transferring via SFTP to the final destination. This means you can keep generated assets (sass files, minified js) out of your git repos, which keeps the committed changesets cleaner and avoids generated code conflicts when working with teams.
The only issue I had when using build tasks with deployments was this occasional error “DeployBot failed to establish or maintain connection to your server.” I found if I added “rm -rf node_modules” as the last step in the build, that resolved the issue. It also sped up the deploy and kept those files off the destination server.
A site I’ve been working on had a list of “recent posts” displaying underneath the main content. The feature used a WP_Query loop to display an image, title, and author link for each recent post.
The client wanted to update this to use a “related posts” algorithm instead, but didn’t want to change anything else about the design or display. That got me curious if it would be possible to fetch the IDs from the Related Posts module in JetPack, but then run them through WP_Query to output the existing custom markup. Continue reading →
The WordPress Customizer does not have a built-in control for setting background images. The background feature simply consists of four different controls:
For this feature, the Customizer also loads javascript that reveals the radio fields once an image has been uploaded. And on the front-end, inline styles are used to apply the background image to the body tag.
If a developer wanted to build additional background image options, the simplest option would be to take the same route: register four settings, load four controls, add custom javascript to show/hide fields if an image is set. Repeat as needed.
However, I started experimenting with a single control and thinking through how that could be implemented.
Issues with Current Implementation
Trac is a great place to find feedback on a particular WordPress feature, and there were a number of suggestions for background enhancements:
A single control generates all the field markup (image, repeat, size, attach, position)
The control also saves an attachment ID if a setting is defined (making it easier to generate alternate sizes)
The control automatically loads the javascript to hide/show the select fields
At the moment, six settings need to be registered (with their defaults and sanitization) if all the fields are going to be displayed. This still feels like a lot of syntax and I’d like to simplify it further- perhaps by saving all the data into a single serialized array for the theme_mod or option setting that is registered.
It also doesn’t address cropping, alternate UI ideas, or retina- mainly just because I haven’t had a chance to explore it yet. But it does have support background-position-y (added to the position field) and background-size (new select field).
I’d love for other people to take a look at this control and give me any thoughts, feedback, or pull requests. You can find the Custom Background Control on GitHub along with all its documentation.
