The team over at Wordfence have put together a study of a particular piece of WordPress malware. What makes the infection they’re calling BabaYaga interesting? This malware fights other infections for control of the site. This has been a little trend in the wider security field; interesting to see it’s come to WordPress.
To monopolize control of the compromised system, these malwares actually patch holes made by other infections. This makes sense, in the wild west any co-infectant is likely to compromise your mission. And what is BabaYaga’s mission:
BabaYaga’s primary function is to generate spam content to be hosted on the victim’s site. These pages are loaded with keyword-heavy and meaningless word salad, designed to attract search engine traffic based on those keywords.
Sounds awesome. :p
The linked PDF white-paper goes into pretty thorough and impressive depth on how BabaYaga works. It’s nto for the faint-of-heart, but it’s pretty cool.
Most web hosting today will have some limitation on the amount of storage they’ll allow you. Maybe it’s 1GB or 20, but at some point, you’ll get near the border of using too much disk space. When you do, you’ll probably have some large files on a cPanel hosting account. And when that’s true, you’ll want to remove them to get back under your storage quota. But it’s not very clear or intuitive how.
Here’s a video showing how I carry out that on SiteGround, our favorite cPanel hosting option:
How to find and remove large cPanel files - YouTube
Walkthrough of Removing Large Files on cPanel Hosting
You’ll need to log into your hosting panel and get the cPanel in front of you.
From there, you’ll look for the “Disk Space Usage” application.
Once loaded, you’ll want to scroll down, as the folder-level view at the top isn’t informational enough. Under the larger gray box, you’ll want change the “Sort directories by” option in a smaller gray box. You’ll select the “Disk usage” radio button.
Once you’ve selected that, you can drill-down into the largest folders (and files they contain) by clicking into the folder hierarchy using the plus (+) icon.
The biggest files on your cPanel hosting will be at the top. When you decide you want to remove the files, you’ll click the link to the folder. That will open up the file browser.
In the cPanel file browser, select the file or files that are too large. If you want, there’s a helpful “Select All” on the bar at the top. After you do, you’ll click “Delete” (with a large red “X” icon) along the top bar. You will be prompted to confirm deletion, if it’s not in error, click “Yes”. The files will be gone!
And that’s how you delete large files on cPanel hosting. Cheers!
Update 6/13/2018: This Beaver Builder review has been revised and expanded to reflect an additional year of using the plugin, and to review the new features in Beaver Builder 2.
This Beaver Builder review is not paid or commissioned by Beaver Builder or any other company. This is my honest opinion as a professional WordPress developer, who builds and manages WordPress websites for a living.
Let’s start with the executive summary. Is Beaver Builder good? Heck yes.
The Best Page Builder in WordPress
Beaver Builder More than any other single plugin, Beaver Builder has changed how I do my work as a WordPress developer, and made good front-end layout building a reality.
Thoughtfully built, feature-rich, and above all reliable, Beaver Builder is the best WordPress page builder.
Now, let’s explore Beaver Builder more deeply. Before that, a bit of set-up:
What We’re Reviewing
This review focuses on Beaver Builder Standard, the least expensive paid version of the main Beaver Builder plugin, currently on version 2.1. No Beaver Builder extensions, themes, or other add-on products are considered.
About the Reviewer
Hi! I’m Fred Meyer, co-editor-in-chief of WPShout. I’ve been a professional WordPress developer for six years, and I’ve written hundreds of WordPress tutorials for developers here on WPShout since 2013.
I first tried out Beaver Builder in mid-2017, and wrote up my experiences in the first version of this Beaver Builder review. I’m writing this revised version of the review after using Beaver Builder actively for over a year, on both my own projects and projects for my clients.
Links to Beaver Builder in this article are affiliate links. My opinions of both Beaver Builder’s strengths and weaknesses are my own. In both this review and my related WordPress page builder comparison review, I’m telling you the plain truth as I see it about which WordPress page builder to use, when, and why. Thanks for reading!
Sections of the Review
Click on a section below to navigate this Beaver Builder review.
Pros: Things I especially love about Beaver Builder.
This section describes what makes Beaver Builder a great tool for a WordPress developer. So it’s about Beaver Builder’s strengths relative to a developer’s other options for creating WordPress layouts.
If you want to know why Beaver Builder is the best WordPress page builder plugin and where others fall short, view the Comparison with Competition section.
It’s Reliable and Well-Built
Beaver Builder is solidly built enough to use without fear on both personal and client projects.
Alone among WordPress page builders, Beaver Builder is solidly built enough to use without fear on both personal and client projects.
Since first trying it in 2017, I’ve used Veaver Builder every time I’ve needed to create complex layouts in a WordPress project, whether for myself or a client. (The only exception is clients that are already using another incompatible solution.)
Across the projects I’ve used Beaver Builder on, I haven’t been disappointed or made to panick by bugs once.
Some Places Where I Rely on Beaver Builder
You can see numerous uses of Beaver Builder on our paid courses site, courses.wpshout.com, where all of our landing and sales pages are Beaver Builder layouts.
Prior to me trying Beaver Builder, we were producing these same layouts with fragile, buggy, restrictive, difficult-to-manage widgetized pages handled through the theme.
I use Beaver Builder for all long WPShout articles, this one included.
I also used Beaver Builder to write this article, because of how much easier it is to visualize the flow of the article when you’re looking at it as you write. I do the same with every long article I write on WPShout, such as my recent one on proper WordPress development practices. Once the article’s ready, I just paste the HTML in its “Text” tab back into the default WordPress editor.
I can also count at least three current client projects that are also running Beaver Builder without incident.
Summing up, I’ve used Beaver Builder for lots of diverse needs, for both myself and clients, and I’ve always been glad I did.
…But Buggier Since Inline Editing
I do have to mention an unfortunate trend here, though. Beaver Builder used to be extremely reliable—free of bugs to an almost spooky extent. It’s actually significantly buggier in version 2, since the early-2018 launch of the inline editor (see “Cons”), than it was in version 1.
It Successfully Streamlines Layout Work in WordPress
Beaver Builder hugely improves and streamlines my work as a WordPress developer.
This is really the key point of this entire Beaver Builder review: Beaver Builder hugely improves and streamlines my work as a WordPress developer.
The first time I used Beaver Builder, in 2017, I ended up working for a bit over an hour. I recorded the process here:
A WordPress Developer Tries Out Beaver Builder Standard - YouTube
(Because the video was lots of me figuring stuff out, don’t go in expecting a guide, or a very organized look at the software.)
I would have needed like 10 incompatible plugins (“Column Shortcodes,” a Font Awesome embedder, a pricing table plugin, and more) to duplicate this functionality without a theme-based solution or a builder plugin, and the final product would have been much worse.
Ever since that sample project for this Beaver Builder review, I’ve used consistently Beaver Builder for complex layouts, because I saw just how much it streamlined my own work.
It Empowers You as a Developer
It’s hard to overstate what it means to be able to create layouts with a consistent tool that works properly.
What needs to be emphasized, over and above the better result on any one project, is how much it empowers a WordPress developer gets to be able to create layouts using a consistent tool that isn’t tied to any one theme or site environment and actually works properly.
It’s incredibly liberating to be free of the theme marketplace (which is mostly a layout marketplace and mostly low-quality) in considering how you’ll meet your own or a client’s layout needs.
And it’s such a relief to be able to invest in getting familiar with a layout tool you can use everywhere, rather than being forced into learning whatever code and UI decisions an individual theme or theme+builder combination might be making for you.
Using Beaver Builder is like finally having a paint roller, rather than hoping that there’s some “roller-like” stuff lying around each house you work on.
All this is what Beaver Builder has done for me in my own work. It’s like doing home renovation and finally having a paint roller, rather than hoping that there’s some “roller-like” stuff (maybe we can wrap a hand towel around a paper towel tube and put a broom handle through it?) lying around each house you work on. Specifics aside, the main thing the plugin has given me is much greater freedom as a WordPress developer, and the importance of that is hard to overstate.
Active Developer and Community Support
Beaver Builder gets much better over time.
Beaver Builder gets much better over time. Since I first published this Beaver Builder review a year ago, the plugin’s developers have given it:
A massively improved UI.
What feels like a significant performance boost.
A full inline editor that’s just about the only buggy part of the Beaver Builder plugin, but that I’m glad exists.
A bunch of additional features (“Beaver Themer” and others) that I prefer not to use.
On that UI improvement, let’s get a bit specific. When I first reviewed Beaver Builder a year ago, this was what I had to work with:
And I liked it then! But I did note that the user interface was a bit, well, plain, as well as clunky, hard to use, and slow.
A year later, Beaver Builder looks like this:
The better UI carries over into literally every piece of the Beaver Builder layout creation experience. They really nailed it, and the plugin is now a pleasure to use—not just something that’s forgivably ugly because it magically works.
Beaver Builder is maintained with obvious passion. It feels like a good technology to invest in.
So, like most things I love in WordPress—WooCommerce and SiteGround being the examples that come to mind—Beaver Builder is maintained with obvious passion by an active developer community who care about doing things right. It feels a good technology to invest in for the long run.
Beaver Builder also has a large, active, and passionate user community around it: a sizable Facebook group of developers committed to the tool, a set of actively maintained tutorial sites organized around it, lots of third-party extensions, and so on.
Beaver Builder is not only the best WordPress page builder, it’s also got a large community people dedicated to using it and making it better, and that’s important.
Beaver Builder Cons
This part of our Beaver Builder review covers my main frustrations with the plugin.
Limited and Difficult-to-Browse Module Library
Beaver Builder has relatively few layout modules, and their bland names and icons make them hard to browse.
Beaver Builder’s choice of modules (the range of layout elements that are available by default) are the one place where Beaver Builder is strongly outshone by most other page builders (including a pretty decent one, Elementor).
There are two issues:
There aren’t that many modules available by default.
The modules’s bland names and icons make them hard to browse.
Here’s what you get:
Click for full size
Even after more than a year, using Beaver Builder’s modules is an experience of: “I wonder if they have what they need. I’m betting they don’t. Wait, there it is! Does it do what I need? Whew, it does. Why is it called that?”
Quick, how is a “Call to Action” (icon: a bullhorn) different from a “Callout” (icon: a bullhorn)? What does an “Icon” do? Is it just an icon, or something else? Does that make it kind of like a “Call to Action”?
This is something that Beaver Builder could do better at, and I’d love to see them expand their default module library as well, as I’d like very much to avoid having to trust third-party “More Beaver Builder Modules” extensions on projects that matter.
Predictably Buggy Inline Editor
Beaver Builder’ inline editor basically works, but it’s got all the usual inline editor bugs, and even adds a few of its own.
I’ve been excited about Squarespace-style inline frontend editing forever. This is where you’ve got a page on the internet and you just start writing: not in a separate “editor” window, but on the page itself. To me, that’s real front-end editing—the way of the future, the way websites should be built—and everything else is a compromise.
Here’s the problem with inline frontend editing, though: it’s really, really hard. Certain problems are essentially unsolvable, because they’re down to the level of “a human being can’t tell a machine all the specifics of what she’s getting at just by writing words onto a page.”
Beaver Builder launched an inline editor earlier this year, and while it basically works, it’s got all the same bugs that earlier attempts in WordPress have had, and even adds a few of its own.
The inline editor adds the character all over the place. Specifically, any time you use the inline editor, inline HTML tags get surrounded with characters.
Let’s say I’m writing the sentence “I like this.” If I do it in either WordPress’s visual editor or Beaver Builder’s visual editor, and then examine the result in either text editor, it’ll look like:
I <em>like</em> this.
Now here’s what will happen if I ever use Beaver Builder’s inline editor to do anything on this page. That markup will change to the following
I <em>like</em> this.
Again, this is if I change anything on the page with the inline editor, not just this section of text. And it’s not just this markup that will change: the first time I use the inline editor, anything on the page that uses inline tags like <strong>s or even <code>s will be peppered with characters.
To give more detail, this bug usually won’t trigger if I stay viewing Beaver Builder’s Visual editor tab. But it’ll trigger immediately if I make inline changes while viewing the Text editor tab. Switching back to the Visual editor sometimes fixes it, but if you publish while viewing Text the markup stays. (And so on, down a rabbit hole of confusing when-to-expect-the-bug details.)
So what’s wrong with characters anyway? Well, besides its not being the markup I want—which is never acceptable—the specific problem it causes is that it causes lines to break early. Whereas “American Revolutionary War” might break onto two or even three lines, “American Revolutionary War” never will, and so there are giant gaps in your paragraphs and blockquotes where things broke onto a new line way too early.
If you care about precision, this is the kind of thing that will drive you absolutely crazy. It’s a familiar problem from other front-end editors, but it makes me wish the Beaver Builder inline editor wasn’t even a thing. There are other bugs, too, like the inline editor somehow occasionally causing links to be written incorrectly, that I won’t cover here.
Puzzlingly Bad Text Shortcuts
The current version of the Beaver Builder inline editor has no way to turn text into headers.
The current version of the Beaver Builder inline editor has no way to turn text into headers.
Given how important a feature need that is, it’s a pretty bizarre omission, and it pretty much dooms any use of the inline editor to be a ping-pong experience back and forth with Beaver Builder’s TinyMCE editor. (More on that in a bit.)
The formatting options the inline editor does give you are at the top of the module—they don’t float with the text. I won’t get into how useless this is on a text module that contains thousands of words, like the one I’m writing now. It’s even bad for a module of a few paragraphs:
The shortcomings of the inline editor force the user to bounce between three editing experiences.
The shortcomings of the Beaver Builder inline editor force the user to bounce between three editing experiences:
The TinyMCE Visual editor,
The TinyMCE Text editor, and
The inline editor itself.
Let’s say I want to make something an <h3>. Can’t do that in the inline editor, better pop over to the Visual editor.
Let’s say I want to use the — character (a long dash, —). Can’t do that in the inline editor or the Visual editor for that, better open up the Text editor. But gotta make sure to toggle back over to Visual before I do any more inline editing or everything’s going to be plastered with s as described above.
The continual need to switch editors creates a distracted writing experience.
There are tons of examples of this problem beyond the ones I’m giving. The need to switch editors goes on and on, and it creates a distracted writing experience that forces constant creativity to do simple things.
You can fix this to an extent by simply never using inline editing—but once you know a text field’s editable, it’s hard to remember not to edit it directly. It’s also sad, because inline editing is by far my preferred way of creating content.
If I didn’t have years of experience writing and massaging HTML markup (and hacking around the bugs of various frontend editors), I honestly wouldn’t want to use this system—a markdown editor would be so much more reliable.
As a closing thought on this topic, I do expect the inline editor to get much better over time, given Beaver Builder’s ongoing track record of rapid improvement.
Comparison with Competition
There are lots of software projects on the internet trying to bring a better authoring experience to users. This section of our Beaver Builder review explains how Beaver Builder stacks up to its competition, both inside and outside WordPress.
Beaver Builder vs. Other WordPress Page Builders
Beaver Builder is the best page builder in WordPress.
Aren’t WordPress’s other major page builders, like Divi and the WPBakery Page Builder, pretty good too?
No, they’re not. Beaver Builder is vastly better than them. In fact, they’re so different in quality that it’s accurate to say that Beaver Builder makes WordPress better, while those two builders in particular..
This website, which we stubbornly insist on reading as “Make Frontends Hit Again,” is about something we can really get behind: returning to making completely useless stuff on the web because it’s cool and fun.
As it says toward the bottom (just past the flashing GIF diamond wall):
We used to make websites because it was fun and at a point we lost the way.
We need to make dumb shit! Make useless stuff; make the web fun again!
All that aside, have a browse. You’ll get hit with the 90’s harder than sipping Surge off an AOL CD.
By the way, if you do notice any display irregularities, the site mentions it’s best viewed with Netscape 3.0. So that’s likely the issue.
If you or your client is working with web images and wondering about web image DPI guidelines, this article’s for you. It explains why DPI doesn’t matter for web images, and why pixel count does.
When we say “DPI doesn’t matter on the web,” we don’t mean “it’s not that important”; rather, we mean “it’s completely meaningless”—like asking about your car’s favorite color. Image resolution online is a function of the pixel count of the image, the size of the space it’s being used in, and the display resolution of the device it’s being viewed on, and of those variables only pixel count is a property of the image itself.
Image resolution online is a function of the pixel count of the image, the size of the space it’s being used for, and the display resolution of the device it’s being viewed on. Of those variables, only pixel count is a property of the image itself.
So what does matter on the web is pixel count. “This image is 72 DPI” tells me nothing as someone who might want to use it on a website. “This image is 2000px by 1000px” tells me everything I need to know about whether it’s large enough to look good if we use it in whatever space we’re considering it for.
The article also answers common questions like:
Does DPI still not matter for how web images display on “high-DPI”/”high-PPI”/”retina” devices? (Correct, it still doesn’t matter, only pixel count does.)
Then how do we change an image’s resolution online? (“Retina” and other high-resolution devices cram more pixels into the same space if they’re allowed to, for example displaying all 1 million pixels of a 1000px-by-1000px image inside only a 500px-by-500px space. So the thing that allows for high-resolution images online is still the images’ pixel count, relative to the size of the space they’re being shown in.)
How are DPI and PPI different? (They’re similar—dots per inch and pixels per inch—and are relevant to physically printing things and building device screens, respectively. Neither is relevant to web images.)
So are rules of thumb like “images for the web should be 72 DPI while images for print should be at least 300 DPI” not valid, then? (Print DPI guidelines do matter, but any sort of “web image DPI guidelines” definitely aren’t valid because DPI is meaningless on the web.)
I Googled up this article just to make sure I wasn’t going crazy, after the second client in under a month asked me about DPI for web images. Really well-written and comprehensive. Kudos to the author!
One of the very few complaints I have about Beaver Builder is that it can be difficult to undo changes—specifically, to undo Beaver Builder layout changes, for which normal “Ctrl+Z/Cmd+Z” undoing within Beaver Builder itself simply won’t work.
There is a way, though! Beaver Builder uses WordPress’s native “Revisions” system to track all the changes you make to each one of your posts. So reverting layout changes in Beaver Builder is not really an “undo changes” button like you’d have in MS Word. it’s more like a simplified Git-style version control system, where you revert the entire post back to a previous version from before the changes you want to undo.
Here’s a video guide:
How to Undo Beaver Builder Changes - YouTube
How to Undo Changes in Beaver Builder
Try Ctrl+Z (Cmd+Z on Macs). This will work for text changes, but not for layout changes such as deleting a module.
To undo a Beaver Builder layout change, open the regular post editing screen for that post with “Edit Post” (or “Edit Page” or whatever the post type is).
Find “Revisions” in the top right near the Publish button, and click “Browse.”
Find the revision that still has the elements you changed or deleted. Note: this will look like very plain HTML, but Beaver Builder is still tracking the markup needed to build your layouts.
“Restore” that revision and reload the page you’re editing.
Continue editing as normal.
As a note, this will only work on post types that have revision tracking, which some don’t—it’s a setting that you choose when you register a custom post type. And it’ll only work on those posts that actually have a revision history: most published posts have this, but some draft posts do not, depending on how long you’ve been working on the draft.
And that’s how to undo changes in Beaver Builder, especially layout changes that you can’t undo through Beaver Builder’s normal on-page system.
One of the first topics I ever wrote about on WPShout, I kind of thought that the topic of “theme creep” had died long ago. But a few times in the last few months–once with someone I’m mentoring in WordPress development, once with someone who was asking how to buy themes–I felt a need to mention this idea. So I’m revising and updating the original essays.
I do think more and more actors in the WordPress ecosystem have “got religion” and are moving functionality into plugins. But it’s still not universal, and quite a few new developers have expressed to me how excited they are about the “everything theme” they’re building. For either of those cases, please consider why you should avoid what I first called “theme creep” back in 2013.
WordPress is great
WordPress is a great tool. If you need to run a basic CMS to get your words and images onto the internet, I’d never hesitate to suggest WordPress. It’ll make it really easy for you to get all that stuff online, and better yet, there are thousands of themes to choose from at every conceivable price point.
This functionality is core to the experience of WordPress. Jumping around from theme to theme without worrying what’ll happen to all your words is an amazing thing. Anyone who’s spent more than five minutes dealing with a static HTML site will rightly be impressed by this feature.
Themes are awesome, but…
But there’s a problem: a lot of WordPress themes break this magical flexibility. Either because of changes the user makes to a theme that was originally aligned with this vision of flexibility, or because the theme wasn’t designed with that flexibility in mind, on a lot of WordPress sites that flexibility has disappeared.
I’ve personally been responsible for ruining this flexibility on my own sites. functions.php is a really easy place to paste functionality snippets you find on the internet. It’s so easy it almost justifies the fact that you’ll lose that functionality when you switch themes.
Commercial themes, especially historically, have been even more guilty. On the outside they offer you immense power, and when you first use them, they seem to keep their promise. The heartbreak comes later, when you finally try to make a swap to a different WordPress theme and weird things happen. All your SEO data, well-crafted portfolio elements, and cool taxonomic structures may be gone. And some of your posts and pages are liable to have these weird [broken_shortcodes] inside of them.
Hmm, the site worked a minute ago…
That’s Theme Creep!
“Theme creep” is what I call it when functionality that has nothing to do with the presentational layer of a WordPress website “creeps” into the theme.
It’s what? “Theme creep” is what I call it when functionality that has nothing to do with the presentational layer of a WordPress website “creeps” into the theme. What this ends up doing is chaining you to a WordPress theme that seem great when first installed. It chains you so that in six months or thirty, when you find yourself wanting a visual change you’re left with a terrible choice: a changed look, or your properly functioning WordPress site.
WordPress themes shouldn’t include shortcodes. They shouldn’t provide SEO panels. They shouldn’t do ecommerce. They shouldn’t provide membership functionality. They shouldn’t create new content types in your site. They should look great, that’s all.
The Real Problem in Theme Creep: Too Much Resposibility
This sort of brittleness of systems typified by theme creep has been bedeviling software makers for almost as long as there’s been software. They’ve even developed some great ideas for preventing it and terminology for explaining it.
One of the most important ideas relevant to theme creep is called the single responsibility principle, which states that every component of a system should have exactly one responsibility and that that component should completely contain that responsibility. For WordPress themes, that would mean that they are only responsible for the visual layout and design of the site. They shouldn’t be responsible for registering data types, or providing for the display of post data in shortcodes, or anything else I’ve mentioned.
How WordPress Themes Should Work
When a WordPress site is working properly, themes can be easily swapped out and nothing is lost in the change. This is a direct manifestation of the single responsibility principle working. Themes only doing visual stuff keeps the system simple and flexible. Visual changes will obviously occur, but nothing other than the look of the site will be impacted, broken, or damaged as a result of a simple theme swap.
And for many themes from many providers, you can count on that promise of WordPress themes being kept.
But in the broader WordPress ecosystem, this single responsibility isn’t always the case. Users, professional developers, and theme sellers are eager to quickly add features without fully thinking through the future implications of the choices they’re making. This leads them to provide gobs of shortcodes and custom post types, even SEO features, that they shouldn’t have in their themes. Those functionalities — which are core to your site and unrelated to its current layout — aren’t things you should rely on any theme for.
How Theme Creep Finally Attacks
They were warned about the Single Responsibility Principle, but they wouldn’t listen!
Initially, the problem is hidden from view, and so WordPress seems to be working better then ever for you. But when you go to change your theme and end up with missing data or a broken site, the true cost of the short-term thinking becomes clear.
Losing data when you change themes is a bummer of a problem, and one that shouldn’t be happening nearly as much as it is. I’ll grant than an expert can solve it pretty quickly because the data’s not truly destroyed (just hiding) but it’s a bad problem.
So beware of themes promising the world: unless you want to stick with that look for the entire life of your site, you should probably not rely on some of those features.
Dealing with WordPress Theme Creep
My presentation about theme creep at and WordCamp Boston in 2013 was great, and the event as whole was awesome. You can see the slides from my presentation, if you’re interested.
Theme creep is a form of technical debt. And technical debt is a problem because it makes a system — in this case, your website — fragile and harder to iteratively improve. Determining that you have the problem is one of the simpler steps you can take, so let’s start there.
Are you a victim of theme creep?
The easiest way to tell if theme creep is an issue on your site is to follow a simple procedure:
Switch from your current theme to one that you know has no creep: I’d generally just recommend one of the Twenty * series, the most recent of which is Twenty Seventeen. Out of the box, these default themes are do nothing from my list of the four things a WordPress theme shouldn’t do.
Once running, go through the front and back of your site looking for things that are broken or missing. That FAQ page is gone? Some posts have broken shortcodes in them? You’re extra taxonomies are missing? Your SEO data isn’t visible to Google? Theme creep got you.
Now that you know you’ve got a problem problem, what do you do?
Remediating Against Theme Creep
To be clear, theme creep isn’t a devastating problem. It can be dealt with relatively easily and productively. The simple problem is that functionality that your sites need always was conflated with the visual appearance of your site today. When you separate out those concerns, your site will be set to move into the future. If you’re not technical, you may need a bit of help implementing these steps, but it’s not too hard. Here are your basic options:
Make an “everything plugin.” This is pretty simple if you know only the smallest bit of PHP. Take the entirety of your theme’s functions.php and put it inside a new plugin. If you’ve never created a plugin before but are interested in trying, I recommend my “Minimum Viable WordPress Plugin” post from a few months back. This plugin probably won’t be able to run side-by-side with your creepy theme — PHP will probably yell at you — but when you’re on a different theme you may well be able to run that side-by-side with you new theme and have everything working. If not, you’ll want to see if your theme is require()-ing or include()-ing other files and bring those over as well. (Either by pasting them in a single plugin file or into unique files as they were in the theme.)
A somewhat better option is to create a plugin for each type of functionality your theme used to do that you now need outside of your theme. This is a better idea overall — you’ll end up with a more modular and flexible WordPress site — but does require a bit of thinking about each bit’s purpose and a real understanding of how PHP works. Your custom post types like FAQs should be a plugin, your site’s shortcodes should be a plugin, etc.
Finally, opt-out from WordPress themes that are creepy. Favor vendors that enforce strong standards with respect to what a theme should do. You get a future-friendly WordPress theme with proven support that won’t weight you down in the future.
As a theme maker or coder, there is more you can do. I’ll not write too much about it here, but TGM Plugin Activiation is a great library and highly recommended if you’re in the position of needing to provide functionality in a theme you’re distributing or selling by know shouldn’t really be in the theme. For marketing reasons, theme seller often fine it useful to “oversell.” And if you “oversell”–advertise your theme using non-theme features–I’m not to upset if you offer the plugins for the features you’ve oversold.
What We’ve Learned
I hope you now have some understanding of this issue that unintentionally infects too many WordPress sites. “Theme creep” isn’t the end of the world, it’s just an annoying and not-helpful entanglement of your theme and actual site functionality. There are ways you can combat it, easily, if you’re a developer. The most important thing is to stay on the look out. Don’t put to much into a theme, and discourse others from doing the same.
There are few brands more synonymous with quality in the web development niche than CSS-Tricks. (A List Apart comes to mind. Smashing Magazine, maybe. We work for you to think of us that way…)
So when I saw that CSS-Tricks had a free text-based walk-through of how to do Gutenberg development for free, I knew I had to share. That Lara Schenck is a coauthor just made it even more important that I do. (I totally mean to name-drop here, but I had the pleasure of meeting Lara at Loop Conf this year. We’re low-key nerd friends because we played a board game and saw Black Panther. :p)
Because of how different Gutenberg development is from what “WordPress developers” have been doing for years, the course is not brief. I’d schedule a half-day or so to read it all and put chunks of it into practice if you want to get the most out of it. But this is a clear, concise, and fantastic free offering from Lara and Andy Bell. It’s got the requisite stuff: what’s React anyway? What’s a block? What’s create-guten-block? All there.
If you’re starting to think you should get to the bottom of this Gutenberg blocks thing (you should!), this is the new de-facto place to start. Do not miss it!
For those who are really into WordPress community events, and world-wide, there’s do_action. For people in the US, there’s something called Code for America, and local brigades. My local brigade is called Code for Fort Collins, and I’m more-or-less in charge right now. The terms for this whole area aren’t super clear for me, some say “civic hacking”, some call it “charity hackathon”, I typically call it “trying to do good” which is maybe less useful. :p
Anyway, it’s been both challenging and fun for me to be involved with Code for Fort Collins. The organization, being 100% volunteer, is really interested and slightly complex to manage. And I wasn’t even intending, initially to manage it. That and more is all in the post. Here’s a quick summary from the post of what CFFC is and does:
As I write this, Code for Fort Collins has about 250 members on Meetup, and about 5-10 regularly-involved members. We’re loosely affiliated (as I think all brigades are) with the Code for America brigade program. We’ve completed a few projects, the most recent is a data-dashboard for Homeward 2020. We made it to aid the organization and the city come to terms with the data-problem that has stopped them from solving homelessness for too long.
If you’re working in this topic area, or would like to be, please don’t hesitate to reach out to me. I welcome it via email, as the most convenient channel. I’m “david” at either this or the Code for FoCo domain.
There are a lot of migration systems for WordPress. We’ve had lots of good experiences with All-in-One WP Migration. Some people swear by WP Migrate DB Pro. Others are partial to WP-CLI’s terminal-based systems. One of the few tools I’d never tried was Duplicator, but I recently did and I love it. I was very pleasantly surprised about a specific facet of it: I don’t need WordPress to get a new local copy of a remote WordPress site running on my local machine. You just pull down two files, put them in the same folder, and then you’re set. It’s great!
Here’s a video explaining how to work with Duplicator:
Create a Local WordPress Development Site with Duplicator - YouTube
And for those who prefer, here’s the steo-by-step how-to:
How to Migrate a Site Using the WordPress Duplicator Plugin
Install and activate, on the WordPress site you’re copying from, the Duplicator plugin.
Click on “Duplicator > Packages” in the left-side menu (it’s be toward the bottom).
In the top right on that screen, click the “Create New” button.
Click through the wizard. That’ll be a blue “Next” button on the “1-Setup” screen, and a “Build” on the “3-Build” screen.
When you see “Package Completed” click the “One-Click Download” link. You should be prompted (by your web browser) to download two files. Save both.
After they’ve completed the download, move the two files (installer.php and something ending with .zip) into the folder you’ll want the WordPress site in.
In a web browser (with your server running) visit the installer.php file.
If everything works, you should see a wizard screen similar to the style you saw in your WordPress dashboard. You’ll need to click “I have read and accept all terms & notices.”
Here you’ll need to have a database ready. Then tell Duplicator your database name, user, and password. For me, that meant creating a new one with MAMP, but this step will vary depending on your environment.
If it all works, you’ll see “Step 4 of 4: Test Site”. There you’ll want to click the “Site Login” button, and log in to your WordPress site using the same username and password as you have on the remote site.
You should now be in a full-fledged copy of your WordPress site. Make sure to clean up after Duplicator. It’ll give a helpful admin notice (banner at the top) showing you think. If you click “Take me there now!” you’ll then be on the screen to click “2. Remove Installation Files Now!” After you do that, you’re done.
It’s pretty amazing how polished and slick the Duplicator plugin is. I know 12 steps looks like a lot, but migrating sites is hard, and in the above I favored small explicit steps. I assure you this is easier than most other WordPress migrations I’ve done in my career. You can hear my surprise and excitement in the video. ;p
Read Full Article
Read for later
Articles marked as Favorite are saved for later viewing.
Scroll to Top
Separate tags by commas
To access this feature, please upgrade your account.