It’s true! In 2020, 80% of websites are still using PHP, 77% use jQuery, and WordPress has 63% of content-management system (CMS) market share.
And, “worse,” the numbers are increasing. Only it’s not really “worse” at all. When you’re running a business it’s not necessarily “worse” to use common, standard technology as long as it performs well, is easy to operate, and as long as people who can support the technology are easy to find and no more expensive to hire than plumbers, electricians, or general contractors.
It’s an uncomfortable secret in the industry that sites that are custom built with more cutting-edge technologies are often very difficult and expensive to modify. The cutting edge moves very quickly, with the result that the hot development stack from just a year or two ago may now be virtually obsolete. With the result that it’s very difficult to find someone who can quickly understand and modify your site without spending hours or days reproducing the old programming environment, let alone mastering the code used to build it.
In my experience as a WordPress developer it’s often easier just to rebuild an older custom-coded site from scratch in WordPress than to wade into the old code.
For better or worse, WordPress has 17 years of practice handling updates. And for better or worse, WordPress has always had a firm commitment to backwards compatibility. And for better or worse, WordPress has had 17 years of tracking down and squashing bugs.
The comic asks what cool new web technologies will be available in 2030. I’m not promising that WordPress will still be the standard web platform in 2030. By 2030 WordPress may no longer be written in PHP! But! Chances are that for any given year in between there will be a decent migration path from “old” WordPress to “new” WordPress, just as there has been for the last 15+ years.
Analogy: is it “worse” that the number of delivery trucks and vans is growing? Not particularly — as business goes more and more online it makes sense that more businesses are delivering products to customers instead of having customers drive to pick them up. And it’s not like delivery truck technology is standing still — they’re becoming more electric, they’re getting better navigation and collision controls, drivers are becoming more sophisticated, and same with delivery scheduling and routing!
It’s the same with WordPress! As more and more people use it, it’s evolving to meet new needs.
WordPress won’t be around forever. But it will still be around in 2030.
A File Manager plugin can be a very useful tool when you need it, but you can say the same thing about a stick of dynamite! It’s not something you want to leave in the kitchen junk drawer in case you need it later!David Innes, owner of RealBasics.com
The ultra-tech website Ars Technica reported a serious problem with an already crazy-risky WordPress plugin. Let me quickly explain how to fix it:
Delete the $%# plugin File Manager plugin if it’s installed on your website!
Done? Good. Now let’s talk about why you really, really don’t want or need the WP File Manager, an FTP client plugin, or any other kind of tunnel-into-your-server plugins on your live WordPress website. (Or any other kind of website for that matter!)
Even if the plugin didn’t have coding vulnerabilities, if you can just breeze into your server configuration from your website then… so can anyone else who can get into your site! In other words, even if the code was 100% secure the feature would still be an intrinsic vulnerability.
It’s always going to be 100% safer, more secure, and probably more efficient to use your hosting company’s control panel or a secure SFTP/FTP tool to access, manage, and edit files on your server. It’ll be a separate login for one thing. For another, hosting companies tend to be waaaay more security conscious and attentive than anyone who might randomly access your website’s dashboard — with or without your permission.
Question: do I think the developers who create plugins like File Manager are bad, wrong, wicked, irresponsible, or dumb for creating inherently insecure tools like a File Manager?
No! Not at all! There are certain cases where you really might have no other way to access your file system:
- you’re locked out of your server, for instance.
- your hosting plan is so old and obsolete that their control panel is basically unworkable
- you’re a contract developer trying to debug a particular issue for a client where you don’t have access to their hosting account and you’ve determined that the problem is with a file or directory that can’t be managed any other way.
Those are all really great reasons! But! They’re all really great reasons to install and activate the plugin, and then deactivate and uninstall the plugin the minute you’ve done what needs to be done.
Want to know the real reason 700,000 WordPress websites have the FileManager plugin installed on their website?
- Because they thought they might need it later
- They (or their developer) added it because they needed it while they were setting up the website but then never got around to removing it
Those are really bad reasons. A File Manager plugin can be a very useful tool when you need it, but you can say the same thing about a stick of dynamite! It’s not something you want to leave in the kitchen junk drawer in case you need it later!
Oh yeah, and on the offhand chance you’re actually using the File Manager plugin and you don’t want to delete it? Log in to your site and update it — the update at least appears to have fixed the code vulnerability. (If not the inherent vulnerability.)
This post is a little bit “in the weeds” for regular business owners, but this might come in handy for more adventurous do-it-yourselfers and less-experienced WordPress professionals.
On a closed Facebook group for WordPress users someone asked
I’ve never converted a Visual Composer website to [another page builder.] I imagine it is a total rebuild from top to bottom? Any ‘best practices’ to convert a site that used VC?
Rebuilding usually is the best bet with shortcode-intensive page composers, though in some circumstances the following information might be helpful. All might not be lost but it can be a bit of a pain if you don’t know where to start.
It’s never a bad idea to rebuild from scratch, since Visual Composer most often comes included in “shovelware” themes that have all sorts of other less… necessary plugins, post types, and “demo” content.
I’ve done seven or eight conversions from shortcode-based page builders or Themes (Visual Composer, Aveda, Divi.) The good news is that the shortcodes tend to come in giant chunks.
The other good news is that DIY and low-cost “professional” sites made with Visual Composer rarely use too many features. These kinds of tools tend to be complicated, so most do-it-yourselfers tend to keep it simple.
The following steps will work for converting to other page builders or Gutenberg blocks, or even plain-old classic pages. So if the site isn’t too weighed down you might try the following:
- Disable Visual Composer and any VC-related helper plugins
- Add your page builder if you’re using one
- Open a page with the editor of your choice
- All the old content will be in one giant text or “classic” module
- There will be acres of [shortcode] blocks.
- With just a little bit of practice you can figure out what’s inside the shortcodes — it’s usually an opening block, headers, images, or sometimes column blocks.
- Cut everything out that doesn’t look like real information (e.g. header text, image links.)
- Next, you’ll need to re-apply header formats and re-insert images from the Media Library. If it’s an information-only page that may be all you need to do.
- If the layout you’re copying is a little more complex you may need to add columns and edit/paste content from the main block into smaller chunks.
- If the layout also includes dedicated module content — for instance galleries, slide shows, or contact forms that are built into Visual Composer — you’ll need to re-create those with new tools.
This is useful mainly for sites with lots of simple posts or pages. You’ll usually still have to rebuild the homepage, the contact page, and other “main” pages with more complex content. But I did it recently for a site with tons of reference pages and once you know what you’re looking for it can go pretty quickly.
So another participant in a private Facebook group for WordPress users echoed something I’d said about the importance of making your own backups.
Similar to David Innes I use [a commercial backup plugin] for Scheduled backups ([cloud-based storage firm] is my choice, but there are many others)…Member of a private Facebook group for WordPress users
And a lot of people when backups have been discussed say “why should I do my own backups when my hosting company does it for me?” – my answer is trust no-one! Make sure you have reliable backups that you have 100% access to in the case of an emergency situation!
It was a great point and here’s how I followed up
Yes! Trust no one is awesome advice when it comes to backups! 😂
(Somewhat) more seriously, virtually all hosting companies do daily backups, and all the halfway decent ones store the daily backups for 30 days. That’s a welcome change.
Less welcome is that they tend to be restore-only backups, meaning you can’t download and archive them. (This makes sense because to save space and processor resources they tend to be incremental rather than complete.)
The downside of that is that after 30 days the backups evaporate. To be fair, if something goes sour pretty much anybody is going to notice within 30 days. But!
- Ransomware often takes that into account and can hold off announcing for 3 or more months!
- With modern caching (CDNS, host-based, etc.) a site’s back end can be totally snarled for weeks or (for one prospect who contacted me) months while still “working” just great on the public side.
- Oh, finally, since I do a lot of emergency-repair work (I really enjoy helping people get back online) I’ve had quite a few clients who don’t notice their hosting account has expired till it’s gone, and I’ve had two clients whose whole hosting provider has shut down and never restarted! In all those cases, server-side, and server-stored backups disappear too.
Anyway, just can’t overstate how important it is to have your own complete, restorable archives in one or more safe places (not just on the server.) Or how important it is to keep copies for at least a year, just in case.
Here’s when RealBasics makes and downloads a backup for our clients
- Manual backup before we start working on their site for the first time (stored for at least three years)
- Manual backup before we start working on their site the next time (stored for at least three years.)
- Automated daily for maintenance clients (stored offsite for about 2 weeks)
- Automated weekly for maintenance clients (stored 156 weeks, a.k.a. three years.)
Bottom line: hosting-plan backups are great. Good hosting companies do the right thing and keep 30 days of daily backups. Restoring from a server backup is almost always dead easy. And…
You still can’t ever have enough good backups!
Our standard maintenance plan includes one hour of consulting a month. In the last couple of days several maintenance clients have contacted me after receiving scary, threatening “copyright infringement” messages coming from their contact forms or other sources.
Here’s one example. Note the suspicious elements.
And here’s another, note the similar email address? Others I’ve seen are [email protected] So it’s a pattern. The email addresses may also be spoofed.
Email: [email protected]
This is Melissa and I am a qualified photographer.
I was puzzled, to put it nicely, when I came across my images at your web-site. If you use a copyrighted image without my approval, you must be aware that you could be sued by the owner.
It’s illicitly to use stolen images and it’s so filthy!
Check out this document with the links to my images you used at XXXYYYZZZ.XYZ and my earlier publications to get evidence of my copyrights.
Download it now and check this out for yourself:
If you don’t remove the images mentioned in the document above within the next several days, I’ll write a complaint on you to your hosting provider stating that my copyrights have been infringed and I am trying to protect my intellectual property.
And if it doesn’t work, you may be pretty damn sure I am going to report and sue you! And I will not bother myself to let you know of it in advance.
“It’s illicitly to use stolen images and it’s so filthy!” It’s misspellingly too! That’s actually fairly common for scammers — they’re not interested in replies from people with great English skills. Or skeptical ones. They want suckers!
Look. It really, truly, honestly is the case that you shouldn’t use other people’s images without permission on your website. And it’s true that you can be asked to take them down, and even penalized if you don’t. For that reason it’s a good idea to have some form of “receipt” for images you use — the URL you got it from, a notation that you either took the photo yourself, licensed it from a stock photo company, or with credit if you downloaded it from a free-to-use creative-commons source. You don’t have to publish the credits (though it’s always polite if you acknowledge free-to-use creators somewhere on your site.)
But it’s very nice to be able to say “oh yeah, #!%! you, I got that image legally from XYZ when someone sends you an actual legal takedown notice. Extra credit? You may be able to sue someone who sends you a false takedown notice!
Bottom line: While you might get real takedown notices if you really are using content that doesn’t belong to you, this “Melissa” character is a spammer and a scammer and you can safely ignore messages from them.
Big hats off to everyone who was smart enough to ask first before clicking that link!
It’s funny how much things have changed since I built my first website back in 1997 or so. It might have been for a hand-coded “blog” I tried to manage all in HTML (not a good idea, but WordPress and precursors like MovableType weren’t really a thing yet.) Or it might have been for an extended family calendar.
Either way they never really got off the ground. Registering a domain name “only” cost $300/year! (Down from $1,000/year!) From the only domain registrar on the planet. If you wanted to actually serve a website you had to have a computer and a static IP address… also a dedicated phone line since back then even DIY web hosting involved dialup access unless you were a really big institution. And that 283×283 pixel photo of the two of us? Back then that was daringly big!
Times have changed since 1997. My son’s now grown, out of college, and on his own! We no longer have to worry about Netscape Navigator 4.0. Or any version of Internet Explorer.
Somethings haven’t changed. For instance most people (up to 85% for some sites and almost all apps) are back to using their phones to access the internet! 😂
One thing hasn’t changed though. I still really enjoy working on websites! It never gets old.
On a WordPress-related Facebook group someone asked…
I’m looking for something similar to Schedulista that can do the following:
-Allow people to book appointments on a website
-Remove unavailable appointments in real-time
-Send SMS/Email reminders to people who book the appointments
-Create a calendar each employee can access from an app
-Open source to manipulate how it appears on a WordPress website
I’ve had clients who use the cloud-based Acuity and Schedulicity appointment managers, and one client has had great success with the self-hosted BirchPress plugin. (No affiliate links, just tools clients have used.) I don’t have very strong opinions about which is best.
My advice is always to look for ones with a well-reviewed companion/connecting plugin for WordPress.
More important, no matter what you choose: look for two-way synchronization with your calendar apps whether it’s Google Calendar, Outlook, Cal, or whatever. It’s WAAAY easier to have the appointment scheduler that automatically blocks out time on your schedule when you have a doctor’s appointment or an unplanned day off.
Being able to enter an appointment once and having it automatically update to your schedule saves you from having to remember to enter those things in two places. Having new client appointments show up on your personal calendar makes sure you don’t overbook yourself with them!
This is all in keeping, by the way, with the internet-authoring goal to “Create Once, Publish Everywhere.” Something I spend a lot of time talking to clients about and really ought to spend more time blogging about as well.
A contributor to a WordPress Facebook had a question about image compression:
I have [an image-optimization] plugin installed to compress my images and I noticed while doing a bulk compression that there are multiples of the same image (in different sizes) that it compressed. I did not do this manually. It seems that something created multiple images in different sizes when I used one. Is that normal procedure or have I goofed royally?
Here’s how I answered
Yes, WordPress automatically generates multiple “thumbnail” images when you upload a photo. The defaults are 150×150 literal thumbnails for galleries, etc. But also 300px “medium” and (I think) 1024px “large” format. A few months ago it started generating hidden 1536px and 2048px thumbnails for… reasons?
Some themes (cough*themeforest*cough) will sometimes generate a dozen or more additional ones for very particular, often-little-used sizes.
it used to be a much better idea to limit the number of thumbnails generated (still is, actually, for those oddball 1900x75px banner liners a Themeforest theme might cook up.) But WordPress now sends lists of available image sizes to browsers so they can pick the smallest, most appropriate size for the user’s screen.
The result is more storage on your server, but sometimes very much faster page speeds for mobile devices.
The good news is that optimizing plugins like Optimole will process all the thumbnails as well as the originals. You might optimize the dickens out of your original uploads, but the server-based thumbnail generating routines WordPress has to rely on usually aren’t as efficient. So it’s a good thing when optimizing plugins do a pass on those as well.
On a Facebook group for the Beaver Builder page builder, someone asked “Maybe a crazy question… Would it be possible to take HTML from another page builder and import into BB?” Here’s how I answered the question.
I did this just the other day (Thursday!) It was a horribly slow site built with an expired version of the popular but old-school Enfold theme/builder. The site broke into a shower of colorful code errors if you bumped the PHP version past the obsolete version 5.6.
So based on my recent experience the short answer is that yes, it does speed things up a little since you don’t have to re-type the content and it’s fairly easy to delete the enormous shortcode blobs that Enfold (and Divi, WP Bakery, etc.) create.
The first thing to do is replace the current theme and disable whatever page builder they were using. (Often they’re intertwined so it’s hard to turn one-off without turning off the other.) In my case when I switched to the Beaver Builder theme the client’s site reverted to a whole mess of shortcodes.
The shortcodes usually have identifying info in them — e.g. column widths, image filenames, colors, etc. And of course I was able to use the original live version as a reference. Between that and the leftover bodies of text it was pretty easy to delete the leftover shortcode text and rebuild the pages.
One big advantage, of course, is that the page and menu/navigation structures are intact. If you’re going to use widgets in your new design instead of Beaver Builder modules and/or the Beaver Themer plugin then you can simply re-add those from the “unused widgets” section of the Appearances->Widgets page.
Another big advantage, sort of, maybe, is that all the images are in the Media Library so it’s a matter of finding them (you can search by the filename if nothing else) and placing them. The downside, though, is that with older sites (this one was from 2016) the images are often too small to look good in full-width situations so I still had to do a little fishing for larger versions.
All in all I’d say it saved me two or three hours on the project.
But there’s no way to do it automatically. (I’ve heard of plugins that will “re-interpret” shortcodes into simple WordPress elements but didn’t find one when I looked before starting the project.)
It’s actually pretty fun — good practice! But only slightly less work than rebuilding from scratch, copying and pasting content from the original site.