Archive of posts with the topic
Today we released Make and Make Plus 1.7. As we mentioned in the beta announcement, it has a lot of big changes under the hood. It also has some great new features! Let’s take a look:
Instant style previews in the Customizer
In 1.7, Make now takes greater advantage of the “postMessage” feature of the Customizer to instantly update the Preview Pane when modifying a style-related theme setting. This includes all Typography, Color, and Background Image settings, as well as many others. Waiting for the preview pane to reload after every font size increment is now a thing of the past!
New interface for managing social icons
In previous versions of Make, you could choose to add icons for your social profiles via a simple form in the Customizer, or as a custom menu. The form was easy to use, but only a limited number of icons were available. The custom menu could accommodate a greater variety of icons, and had more flexibility, but it was not very intuitive to use. With Make 1.7, the two methods have been consolidated into one interface within the Customizer. Paste your social profile URL into the field and watch the icon appear instantly. Drag and drop the icons into any order you want. And with the Social Icons API, you can add even more icons to the list of 53 that are currently available.
Color and typography settings for buttons
Now you can customize the colors and fonts of built-in buttons (comment form, search) and Gravity Forms buttons from right in the Customizer.
One-click migration of theme settings from the parent to the child
Have you ever started a new Make site and gotten everything configured just the way you want it in the Customizer only to realize that there are a few more tweaks you need to make with a child theme? And then, when you activate the child theme, you realize that everything is back to the defaults in the Customizer, because WordPress treats it like an entirely separate theme? Well, we know from supporting our users that it happens a lot. Now when you have a child theme activated, there’s a new “Migrate Settings” entry in the Appearance menu where you can copy all those changes you made in the Customizer from the parent over to the child. Hallelujah!
Make Plus: Sticky headers
With this oft-requested feature, you can choose to have either just the Header Bar or the entire site header remain fixed at the top as you scroll down the page.
Make Plus: Improved Typekit interface
The process of entering your kit ID and loading the contents of your kit into the list of available fonts has been significantly streamlined. Simply paste your ID into the field, and it will instantly test the kit and indicate whether the fonts loaded successfully. Then just head over to any Font Family dropdown and your fonts will be there!
Make Plus: Improved interface for post and page layout settings
We heard from a lot of people that the interface with “the double checkboxes” was confusing at best, so we changed it to be more intuitive.
New users can download Make 1.7 today. Make Plus users — make sure you’ve authorized your plugin to get one-click updates in your WordPress dashboard.
Make 1.7 is now in beta! This release has a lot of big under-the-hood changes, and we need your help with testing so we can make sure the update is as seamless as possible. Especially if you are using a child theme that makes any customizations involving PHP, we need your feedback!
As they say with WordPress core betas, this software is still in development, so we don’t recommend you run it on a production site.
The beta of the Make theme is available here.
The beta of the Make Plus plugin is available to Make Plus license holders. Find it in the Downloads section of your account.
Update: Make & Make Plus 1.7 have been released!
If you think you’ve found a bug, please create an issue on the Make GitHub repo, or send an email to email@example.com and note that you’re testing the beta.
The focus of this release was improvements to theme settings and how they are presented in the Customizer.
Here’s a rundown of the front end and admin changes in Make 1.7:
- Instant style previews in the Customizer
- A new, improved interface for managing Social Icons
- Color and typography settings for buttons
- Support for the Custom Logo functionality introduced in WordPress 4.5
- One-click migration of theme settings from the parent to the child (coming soon)
And in Make Plus 1.7:
- A new, improved interface for Typekit
- An improved interface for single post and page layout settings
- An option to make the site header “sticky” (coming soon)
- Style Kits and the Builder’s Quick Start templates feature have been removed
The biggest changes are actually behind the scenes. As Make has continued to evolve and grow in popularity, we’ve realized that we need to be more strategic in how we maintain code and build out new features.
When we first built Make, most of the functionality was implemented the same way you see a lot of things in WordPress core: lots of procedural, global functions. This strategy keeps the code easy to follow and familiar to those who develop themes and plugins for WordPress. However, it also tends to lead to a couple of common coding pitfalls:
- Big, complex functions that do too much and can’t be reused
- A lot of small utility functions in the global public scope that may become dependencies for unintended purposes
What we’ve done in Make 1.7 is deprecate a lot of these global functions and encapsulate related functionality into “module” classes (Note, though, that we aren’t using namespaces, so Make is still compatible with the same minimum version of PHP as WordPress). This allows us to have smaller, more abstract functions that are kept to their intended scope, which makes our code DRYer, more flexible, and easier to test. This in turn lays a robust foundation for future enhancements to the theme and plugin.
Moving away from pluggable functions
The other thing we did when we first built Make was to make nearly all of the functions in the theme “pluggable”. This allows child themes and plugins to override an entire function by defining it before it gets defined in the theme. WordPress core also has pluggable functions, although it is no longer considered a best practice and they are no longer being added.
These pluggable functions in Make can cause problems, because they limit the effectiveness of improvements and iteration of the code. If a child theme overrides a function, we can no longer be sure that the function will return the expected value. If we change the logic within the parent function, the child theme’s version may still be using some or all of the outdated logic.
Many of Make’s pluggable functions are now deprecated in 1.7. In some cases we’ve added new action/filter hooks to maintain customizability.
A full list of deprecated functions is included at the end of this post.
WordPress has a class for handling errors, but it doesn’t have a very good way of surfacing these errors. Since Make 1.7 deprecates a lot of code, we needed a way to display the deprecation notices that would get the site administrator’s attention without disrupting or breaking the layout of the site for visitors.
What we came up with is a notification in the Admin Bar that only displays for logged in users who have the capability to install/change themes.
Click on the notification, and an overlay will appear that displays the Make error messages and a backtrace to the location of the error in the code, when possible.
These notifications can also be turned off via a filter, but it is more advisable to fix the errors instead. ;)
Moving to a modular architecture gave us the opportunity to expand the theme’s APIs to improve developers’ abilities to go further with their Make sites. We haven’t completed the documentation for these APIs yet, but here are a few example uses:
- Settings: change default values, specify sanitize callbacks that automatically run when the setting value is retrieved.
- Fonts: add your own web fonts and make them available in the list of font families in the Customizer.
- Social Icons: change or add to the available icons in the site header/footer.
The following functions are deprecated. They will trigger a Make error if used or overridden in a child theme. If there is a direct replacement for the function, it will be called instead.
Deprecated action and filter hooks
The following hooks are deprecated, but will continue to work without disruption. They will still trigger a Make error, however, so their use should be discontinued.
Update: Some of the hooks that were previously listed under “no longer used” have been moved up to the “continue to work” list.
The following hooks are no longer used in the code. They will trigger a Make error, and functions added to the hooks will no longer be called.
A few months ago, we asked Justin Tadlock and Emil Uzelac, of Theme Review, Co. to undertake a code review of Make and Make Plus. For those who don’t know, both are senior reviewers at WordPress.org (and Emil is now a reviewer at Envato). It was humbling — and also a great experience to have these two well-respected theme experts in the WordPress community take a deep dive into our code and scrutinize every line.
Now that we’ve had some time to collect our thoughts on the process, here are some of the things we learned from Justin and Emil’s feedback, that we think will help other theme developers better their own code.
Translated strings should be escaped too
Justin and Emil noted that we had done an excellent job escaping output from the database and user inputs. This is a standard practice for keeping code secure and preventing XSS vulnerabilities. However, one area that we had overlooked in some cases was translatable strings. Any string that’s included inside one of the translation functions, such as
__( ‘Hello world.’, ‘make’ )
will be replaced with the corresponding string in an .mo file, if it exists. Each language has its own .mo file, usually provided by a different translator. Theoretically, malformed or malicious code could be included in an .mo file and get inserted into a page load when the default string is swapped out. The way to prevent this from being a security issue is to use the escaped version of each translation function. So then
__( ‘Hello world.’, ‘make’ )
esc_html__( ‘Hello world.’, ‘make’ )
We have always reviewed each of the translations that we ship with Make to ensure that they didn’t contain anything malformed or malicious. But since we can’t control custom translation files or translations provided through the WordPress.org theme translation project, escaping all of our translation strings provides an extra layer of security hardening.
Good translator notes make for better translations
Speaking of translations, our theme had several instances where a translatable string, taken out of context, was practically meaningless to anyone trying to translate it using the theme’s .pot file. Justin and Emil helped us identify several of these instances and pointed out that we could provide context in a code comment near the translation string, and it would be included in the .pot file. Example:
Old .pot file entry
New .pot file entry
#. Translators: this string denotes a camera f-stop. %s is a placeholder for
#. the f-stop value. E.g. f/3.5
Some things actually shouldn’t be prefixed
One of the first things that’s drilled into your head as a WordPress developer is that everything should be prefixed so that your code will avoid collisions with other plugins’ code as well as core WordPress code. So in Make, all of our functions look like this:
Many of our CSS classes look like this:
One exception to this best practice is when it comes to naming 3rd party libraries. In Make, we include the Font Awesome icon font library. So do many plugins. If we all prefix our libraries with something like “ttfmake-font-awesome”, users may end up loading multiple instances of Font Awesome on a single page. If, however, everyone uses the same name, “font-awesome”, we can ensure that WordPress will only load the library once.
Clean, uncluttered templates make life easier for child themers, and for us
Justin and Emil noted that in several of our template files, we have a lot of logic to execute before we even get to the HTML. If you need to override one of these templates in a child theme, having all that logic in there adds a lot of complication, as well as increasing the risk that a future update of the parent theme will cause the child theme to become incompatible. For us, this increases the possibility that we will have a lot of redundant code spread throughout multiple template files.
The solution is to move much of that logic into functions elsewhere, and simply use those functions to bring only the pieces of data you need into the template files themselves. This is an area that we’re still working to improve.
Getting a third-party code review is totally worth it
If you’re a theme or plugin developer, and you’re on the fence about having your code reviewed, either before you release it into the wild or even for an established product, we’d encourage you to go for it. Reacting to user bug reports and feature requests will only get you so far in terms of improving your codebase. Getting objective feedback from a trusted third party will not only help you make your product better, but it will help you learn and grow as a developer — both of which are worthy investments. We take pride in the quality of our code here at The Theme Foundry, and getting third-party feedback on it has been a valuable part of making it even better.
So how did Make fare?
In Justin’s words:
I’ve reviewed 100s of WordPress themes and plugins over the years. I’ve seen the good, the bad, and the ugly. However, I can count the number of times on one hand when I’ve seen works of art. If code is truly poetry, then The Theme Foundry is the Shakespeare, Dickinson, and Whitman of our time, all rolled into one. Make and Make Plus represent some of the finest work I’ve seen.
Version 1.5.0 of Make was released into the wild today, and we’re pretty excited about the changes included in this release!
In version 1.5.0 of Make, the Customizer gets an overhaul. We’ve added a bunch of new theme options, improved the interface for controlling some of them, and reorganized things to make everything easier to find.
Inspired by the Kirki project, we added some new Customizer controls:
A range slider for adjusting numbers. These are used for font sizes, line heights, letter spacing, and more.
Button sets, which are easier to toggle than a dropdown. These are used in many places where there are a small number of options to choose between, such as font weight, link underlining, and the site layout.
New Typography Options
Make 1.5.0 includes several additional typographic properties that can be adjusted, including font weight, font style, line height, letter spacing, and word spacing.
We’ve also introduced a few new customizable elements in this release, including sidebar widget titles, and footer widget titles and bodies.
You can now also customize whether links in the header, body, widgets, etc., will be underlined.
We’ve also enhanced the font family dropdowns in 1.5.0, making it much easier to find the font you’re looking for among the 500+ Google font options.
New Color Scheme Options
Make 1.5.0 includes several new color options that will override parts of the global color scheme when set. These include header and footer colors, menu colors, and widget colors. We’ve also added separate color options for various links when they are in their hover/focus states. And for background color options, Make now includes accompanying options to control the opacity, so you can have semi-transparent (or entirely transparent) backgrounds.
For background images, we’ve enhanced the standard background position option so you can set both horizontal and vertical positioning right from the Customizer.
Updates & New Integrations
In addition to a couple of bug fixes, we’ve updated to the latest set of FontAwesome icons, added a new Russian translation, and added style support for Postmatic. Check out the complete changelog for more details.
For Make Plus, version 1.5.0 is mostly a compatibility update to keep up with these changes in the Make theme, and is a recommended update for all users. Stay tuned for some exciting new features we’ve got planned for Make Plus in upcoming releases.
When you have a moment to update your theme, let us know what you think of these new features. And if you haven’t tried Make yet, download 1.5.0 right now for free and give it a spin. We’d love to see what you’re putting together with Make and Make Plus, so please do share your creations!
Thanks so much for all your support and enthusiasm!
If you’ve ever switched WordPress themes, you know how frustrating it can be to tweak your site to perfection while it’s live. The whole world can view your changes in real time, not to mention your mistakes. It’s far from ideal, sure, but what choice do you have?
All themes from The Theme Foundry come translation-ready. Instead of making you create a file containing the human-readable text from a particular theme, we’ve included that file with the theme itself. All that’s left is performing the actual translation, which is where you (or a professional translator) come(s) in.
Why translate a WordPress theme? For starters, around 44% of WordPress websites are written in a language other than English. People all around the world use WordPress!
Translating a theme can also help you “localize” it for a specific lexicon. For example, our friends in the UK might “get ‘round to” a task while Americans simply “get to” it. Localization can help you tailor a theme to the vernacular of a specific country or region, if you so desire.
Tip: Use a virtual private network to research common terms that appear on search engine results pages in other countries.
We’re about to show you how to translate our themes. But first, let’s examine the three types of files involved in the translation process:
As part of ongoing efforts to improve our Make theme for WordPress, we’re proud to announce several new enhancements. All of the following updates are available in the latest versions of Make and Make Plus. Download Make for free to see the biggest, most sweeping changes in action!
If you’re staring at a white screen wondering where your WordPress website went, you’re not alone. Nearly every avid WordPress user has experienced the fabled “white screen of death” at one time or another. It’s a pain when it happens, but it’s usually easy to fix.
We’re about to explore several common causes of the white screen of death – from plugins to PHP and beyond. If you need to get rid of a white screen and recover your website right now, you’ll learn how. And if you’ve tangled with the white screen of death previously, don’t click away yet! We’re going to discuss various white screen scenarios, some of which you may not have encountered.
Last week, WordPress 4.0, “Benny,” became available for download or automatic update in your WordPress Dashboard. Enhancements include improved media management tools, easier video embeds, and a more immersive editor – all in all, it’s an extremely rich update with lots of new features.
However, we think there’s one exciting aspect of 4.0 that many observers have underemphasized: a collection of changes to the Customizer.
While the Customizer received a number of improvements, the change most users will notice is the new panels interface, which makes it easier to view comprehensive, contextually-appropriate theme options right from the Customizer.
We like this change a lot. In fact, we’ve taken full advantage of it with the latest version of Make, our drag-and-drop theme featuring custom layouts.
So you want to change this one small thing in your WordPress theme. How do you do it?
It’s a question we’ve addressed on our blog before. Covering everything from the basics of CSS, the pitfalls of editing your theme’s core stylesheet, and the concept of WordPress child themes, the following posts were extremely well-received by our readers:
If you haven’t read those posts yet, we recommend checking them out before proceeding further. You’ll learn how to customize your theme with a child theme, which is usually the best method. This post is for readers who want to customize their theme but, for one reason or another, aren’t sure whether they should use a child theme or a plugin to add custom CSS.