Today we released version 1.8.2 of Make and Make Plus. Back in version 1.8 we refactored our builder backend code, and 1.8.2 we’re patching up several little issues reported by makers. Here’s what’s included:
Fixed an issue with notices incorrectly displaying when Make Plus wasn’t installed.
Fixed the Banner sections “Darken background to improve readability” setting.
Fixed an error with Gallery images when “Aspect Ratio” was set to “None”.
Fixed Posts List “Type” field which wasn’t updating “From” dropdown with the correct data.
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.
by Melissa Hill on April 8, 2016 /
Comments are closed
You can make a pretty good case that an engaged community ultimately forms the basis of any healthy business. At The Theme Foundry, we have several levels of community. We have our premium support forums here, where we give help and think through solutions with our users. We have our community support forums that we maintain on WordPress.org — which anyone can access to get help with Make. And we have specialized communities — like our Slack channel for Make Plus Professional members.
For the most part, due to the sensitive nature of the topics posted in our forums, we’ve chosen to keep our communities closed. Our members overwhelmingly prefer this for privacy and security reasons. Our Slack communities are more akin to “masterminds” and we try to foster collaboration and share in one another’s successes. So far, we’ve chosen to embrace the closed model for our communities, but lately, we’ve also been considering a more open community for Make users to jam on their site ideas and needs.
In last week’s episode of #CMGRHangout, I had the opportunity to chat with other community managers on the subject of open vs. closed communities. Watch the replay here:
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.
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.
If you’re ever interested in the pain points associated with WordPress, you should ask someone in the trenches of providing technical or customer support. We’ve heard it all, over and over again. One recurring theme I’ve noted since my tenure in the support forums is this: users are afraid of installing plugins.
The original tickets are usually about some feature they need on their website. I’ll pick a common example we’ve dealt with — a mailing list subscription form. A user, we’ll call her Jane — asks her theme authors, “How do I add a mailing list subscription form to my website?” and we explain, “The theme doesn’t include this kind of functionality. But you can install a plugin to do this for you.”
Jane balks, “I’m trying to avoid plugins.”
I’m sure the first time Jane installed WordPress, she was giddy with power. She instantly sought out a new theme to change the look and feel of the front page. Because the more modern-looking and featured themes on WordPress.org are typically well-maintained, this experience likely went pretty well for her. Change theme = success.
Next, Jane learns about plugins. Understanding that plugins add all kinds of cool things, Jane searches for a social sharing plugin. “This plugin hasn’t been updated in two years…” Well, it’s here in the search! “This plugin hasn’t been tested with your version of WordPress.” What does that even mean? Install, activate. Best case scenario? Sidebars look wonky. Worst is the white screen. What kind of experience has Jane had now? Plugins = things breaking.
Then something magical happens. Jane notices a theme that includes social sharing functions. A lightbulb goes off in her head. It will just work, and that’s all that matters to her.
It turns out, the WordPress plugin directory is not the greatest resource for people seeking out well-maintained plugins. Developers might initially have altruistic intentions when they added their plugin, but it’s all too easy to get overwhelmed by the demands of support and maintenance, so abandoned plugins abound. It’s one thing for WordPress folks to understand this is essentially a volunteer gig — but it’s not easily communicated to the other sixty million users out there who expect things to just work by virtue of it being listed on the website.
On the other hand, there are also so many brilliant and useful plugins out there — built by passionate, professional, and generous community members. It’s just harder for new WordPressers to sort those out in the search results.
We shouldn’t be avoiding plugins at all. In fact, I wholly advocate going plugin crazy. Just be smarter and more responsible about it. Look for plugins that have been updated in the last year (at least!). Check out the developer’s other work and suss out whether they’re valued members of the community. And…
Don’t avoid plugins, review them
Most of all, I think we all should be writing useful and insightful reviews for the plugins we’re using — when they work well, and when they don’t. Keep in mind that a review is not the appropriate place to request support. If something is broken, it’s really important to open a thread on the appropriate support forum — even if you end up moving on and using a different plugin.
If the WordPress community would be better about those two items, users would have an easier time sorting through the results for well-supported and updated plugins. I recently went through my own website plugin list and left a review of each one I’d activated and used. I even wrote a review for one I activated and liked, but ended up going with another I liked better. I explained the feature difference in my review, and I hope it’s useful to the next person whose looking for a fancy Instagram integration. 🤓
Here’s a template you can use for your own plugin reviews:
I installed[plugin name] on my blog/business site/portfolio.
The plugin has these features which I really like:
I wish these features could be improved upon:
These features didn’t work for me, even after I tried to get support in the forum:
Overall I would recommend/not recommend this plugin if you’re trying to accomplish __________.
I get that reviews and open threads in the WordPress.org forums alone won’t solve the problem of abandoned or poorly coded plugins. I know that we’ll still see unfortunate conflicts between plugins and themes. But I think as a community, we could do a lot better about flagging what we notice. Who knows, your review or your open ticket just may save some new WordPresser from the panic that goes along with their very first white screen of death. It could even save someone from getting so frustrated with WordPress that they jump ship altogether.