Updating a plugin can quickly become a nightmare for both the users and developers. Discover how we proceeded to make a smooth transition from Weglot v1 to v2.
Why did we need a new version? Before explaining how we proceeded with a new version, it’s important to understand “why” we had to make a new version of Weglot. The main reasons were to improve the “adaptability” of our plugin and to reduce our technical debt.
An increasingly long and difficult support
The first version of Weglot did not contain any WordPress filters or actions: the so-called hooks. It was thus very difficult to change the default behavior of our plugin and adapt it to specific customer needs. We had to provide custom patches to our customers while taking into account the changes for our next updates. It was quite tedious and delicate. The more customers we had, the longer the technical support was. Of course, we could have simply added some filters and actions as we went along, but we were faced with other problems.
A growing technical debt
Here is the quality score of the Weglot WordPress plugin code at the time of the last update of version 1 (v1.13.1): 6.53 / 10
Generally speaking, we can’t say that it’s a terrible score but it’s clearly not great either. The mediocre score was partly due to some of the dependencies
Gutenberg continues to spread throughout the development community. I'm no expert on Laravel, but I find this fascinating.
If you work remotely or manage a team of remote workers, these are the tools that we use and/or recommend. Check them out and boost your productivity!
Any job requires planning, organization and communication, but remote work needs all of those things ten-fold. Working remotely comes with its own set of distractions, depending on how and where you work. Distractions might happen in the form of the hustle and bustle from your favorite coffee shop or the attention needed by your pets or young children. In my experience, working from a home office tends to have a series of challenges to overcome day-to-day problems that could prevent me from getting work done, if I wasn’t otherwise prepared to handle it. It’s important to get yourself working in a way that makes sense for you so that you remain organized, working efficiently and well-connected. Here are a set of recommended tools doing just that, while you work remotely. These are, admittedly, the ones we use or that I like best, but I’ll list a few alternatives with each, too.
This recommended tool is probably not a surprise. Communication, in my book, is the most critical aspect of any successful relationship—work or personal—it makes no difference. Slack is an excellent chat-like environment for teams. It permanently removes the needs for email
When building a #WordPress theme in 2019, there are certain things to consider. Learn what's required, what's new, and some ways to clean up WordPress for the frontend and for users.
WebDevStudios (WDS) is working to improve our theme framework wd_s based on Automattic’s _s; although at this point, it’s resemblance is only vaguely similar. WDS is dedicated to keeping up to date with the web development industry and making educated decisions about which new things to pursue and which to ignore (for now). In my private time, I’ve been building a starter theme from scratch to better educate myself about what is required by WordPress to build a theme-repo-approved theme but also to make my own informed decisions based on what others are doing, how people typically use the internet, and what of WordPress core feels antiquated.
I started writing this blog post to try and build a custom theme from scratch, but that proved too problematic for a few reasons. The time commitment wasn’t small. Any theme I built would require more than just one blog post and there’s a world of information out there to help you on your way already. Also, before any opinionated decisions had been made, the outcome was essentially any other theme out there already. The biggest reasons I thought I’d circle back and rethink this post was because a lot of those
We analyzed 13 billion log entries. Here's what we learned about the WordPress hosting industry.
Judging a theme by looks alone isn't wise. Instead, dig a little deeper to learn about accessibility, efficiency and attention to detail.
One of the first steps to building a great WordPress website is finding the right theme. Yet, this can also be an incredibly tough choice. Why? Because there are so many themes. And it seems like each one promises the moon, stars and a slice of pizza. When you think about it, themes carry an incredible amount of responsibility. They not only have to make our content look pretty, they must also make it easy to navigate and consume. Plus, they have to effectively adapt their layout to everything from a small mobile screen all the way to a 60” 4K monitor. And this is just scratching the surface.
In such a crowded marketplace of free and premium themes, how can you choose the right one? While there’s no one-size-fits-all answer, there are some general characteristics to look for. Here are a few of the most important ones to consider.
1. The Ability to Turn Off Unused Features
Deadlines are important. But unreasonably tight deadlines that encourage clients and their developers to cut corners and skip steps could be detrimental to the success of your WordPress website. Here's why it's a bad idea to rush your website project.
It’s no secret that website project timelines can sometimes be unreasonable. Clients have many different reasons behind the timeline goals set for projects. It could be anything from the release of a new product, a big marketing campaign, or an event. The target date is almost always important and firm. In managing website design and development projects for over half of my career, I have become very familiar with timelines that clients desire, especially tight timelines. As an agency, we’re always doing our best to hit and exceed client goals, but there are times when it’s a bad idea to rush your website project.
A website design and development project typically takes 12 weeks (or more) from initiation to completion. There are various phases throughout a project life cycle that are critical in ensuring a performant and secure website that delivers what the client is expecting. When you rush a website project to hit a particular goal date, you risk a lot.
Discovery is so important.
Rushing a website project typically means starting the development phase ASAP. This is a huge mistake.
The discovery phase of a project provides time for the Engineering Team to explore
In Rachel's latest quick tip, she reviews what an archive is in WordPress and how developers can make use of them.
Whenever I’m talking WordPress to someone, I have a habit of using terminology that is specific to WordPress. Problem is, not everyone is familiar with said terminology, and sometimes I need that reminder. At the same time, I want those that I work with, to become comfortable with the WordPress “lingo” being used as it probably won’t be the last time they’ll encounter it. That is my inspiration for this newest quick tip. We’ll be diving into one of these words that I say often – the “archive”. What is a WordPress archive? How can we, as developers, benefit from it? The literal definition vs the WordPress definition
First, let’s go over what this mysterious archive is. Here is the dictionary definition of an archive:
A repository or collection especially of information.
In WordPress, an archive is the same. It is a collection of information, or in this case, WordPress posts, based on a commonality.
That commonality can be several things, and there are several archive types in WordPress. Now what do I mean by commonalities? I mean that archives group together posts that have something in common.
The good news is, WordPress does
Face 2019 with some new knowledge of your website. Read over these design and development myths and learn what you can do right in the new year.
I’ve written about New Year website prep before and how this is a popular time to give your website a good once-over for the new year. You can read Get Your WordPress Site Ready for the New Year: What to do Now! for some helpful ideas on getting things running smoothly. Every client that I work with has ideas about what their new or existing website needs without really thinking about what it means for their website in the long term. New or potential clients have their own misconceptions around their potential websites as well, so I thought it might be helpful to talk about some design and development myths or misconceptions and address them so you can face 2019 with some new knowledge. Myth: Sliders and Hidden Content Are a Must
Let’s make a resolution right now: no more carousels, sliders, modals or accordions.
Learn about the benefits of Headless WordPress with React and NextJS from a Senior Frontend Developer at WordPress development agency WebDevStudios.
We recently discovered a situation where we were able to find some fun and interesting ways to extend our standard ACF Flexible Content Blocks. Let's dig in and find out what we did!
Here at WebDevStudios, we do quite a bit with Flexible Content Blocks in Advanced Custom Fields (ACF). If you aren’t familiar with the plugin, ACF allows for the creation of a multitude of custom meta field types using a graphical user interface (GUI) in the WordPress Dashboard. You can do almost anything with these fields—from simple text and URL inputs to searching for posts and pages and building image galleries. ACF allows you to power your site with robust customization options, which you can use to create and manage dynamic pages. Instead of being locked into a set of page templates where the functionality and layout are tied directly to the theme’s files, building pages with ACF Flexible Content Blocks puts the power of customization into your hands as a site manager and editor. You can add, remove, and rearrange blocks as needed and have full control over the content within each of those blocks.
Sometimes, though, simply customizing the content within those blocks isn’t enough. Sure, it’s nice enough to be able to edit the title of a block or select a different set of Featured Posts to display. But, what if you don’t want to have to get that
This... this is absolutely the right solution. Hope it happens.
Over the past week, developments which I predicted back in December last year have come to fore, and I am deeply concerned about the effects they will have on WordPress (the application) and the community unless we take decisive action. Short version: For various reasons, many WordPress users will be faced with a complex dilemma when 5.0 and Gutenberg comes out:
a) Get the latest version of WordPress and risk compatibility issues / costly retraining, redesign, or entire rebuilds, and/or other problems, or b) choose not to upgrade and end up running an old and eventually insecure version of the content management system.
So far, the response from WordPress leadership has been to install the “Classic Editor” plugin which as the name suggests reintroduces the classic WYSIWYG editor once the Gutenberg Block Editor becomes the default. This is, in my opinion, a dangerous road to go down both for the end-user and WordPress itself.
Classic Editor as a permanent solution won’t work
Classic Editor is a bit like using a band-aid to plug a hole in a ballon as you are inflating it. It may work right now, but as the balloon continues to grow, the band-aid not only won’t do
Creating a fresh website is exciting, but there are certain things to consider. These are the rules of a redesign. Follow them and reach success.
There are a large number of considerations that need to be addressed before you redesign or rebuild your website. I’ve written many things on the subject in long form, but I thought it might be helpful to break these down into a quick-to-absorb “Dev Shortie.” None of these considerations are outside the realm of common sense, but the excitement of redesign opportunities that become available when building a fresh website can make us tend to forget why we need something new or who we’re doing it for. So, let’s get into it. These are the rules for your redesign.
Rule 1: Have a Reason.
Have a valid reason for your redesign. “I want something new,” isn’t a valid reason. “Our current website is not accessible,” and, “We don’t have a mobile responsive design,” are valid reasons.
Keep in mind that the level of redesign should be in line with the weight of the reason. For example, “We’ve completely changed our identity and branding,” would carry more thought, weight, and work compared to, “We have accessibility contrast issue on our current site.” You must address accordingly.
WDS Senior Frontend Engineer, Jo Murgel, presents a better process for styling websites. Keep things clean, organized, reusable, and readable.
One thing I’ve noticed a lot lately with websites is that no matter how it looks, the style sheet is full of redundant, duplicate, or unnecessary styles. A lot of that, I imagine, comes from updates after a website goes live, where engineers that weren’t initially involved in its development are coming in blind. Another part of that might revolve around planning or distribution of tasks for a website’s construction. Truth be told, there are probably dozens of reasons that the styles may not be as organized or clean as they could be. We can’t see the future and we can’t always be in constant communication with one another, but I’ve learned a thing or two over the last decade that I think might help keep things clean, organized, reusable, and readable.
Before We Start
A few setup notes here: I write my styles with SCSS. This is my preference. There are many other options out there—Less or Sass to name a couple—which will work in more or less the same way. I also typically use webpack or Gulp on older projects to compile and minify, auto-prefix, and concatenate my style sheets.
Organization and Breakdown
The organization is really up to the
There are plenty of ways you can rely on reusable code snippets to save time and provide you with the best possible work and turnaround.
When was the last time you started a project from scratch? I mean literally from scratch—not using a framework, a parent/child theme, or any plugins. Maybe never? One could argue that as long as you’re using WordPress that you’re not necessarily creating anything from scratch since the CMS offers so much functionality out of the box already. What you do, though, is iterate on that functionality and build upon the tools provided to you or the tools you have built for yourself in the past. After all, if you’re doing work around the house and need to hammer some nails into the wall, you’re not going to head into your garage to carve the wood and forge the steel to make a new hammer every single time (unless you’re our very own builder and wood magician Will Schmierer). You’ll use the same hammer to do the same job until the hammer is no longer useful or you find a new tool with which to replace it.
Why then would you not develop a site in the same way? Granted, most projects are going to require distinct sets of functionality unique to the projects themselves but there are plenty of ways you can reuse code to save time so you can truly focus on
Because the Classic Editor is going to be around for a little while, does it make sense to use it on a new build?
As software evolves, we can find ourselves having to adapt to new ways of doing things. There’s a learning curve involved that, while frustrating at first, becomes second nature once we have put in the requisite practice. WordPress, however, has provided us with a choice. We can adapt to the new Gutenberg block editor, or we can stick with the tried-and-true Classic editor.
Generally speaking, “legacy” solutions such as the Classic editor are often phased out rather quickly. Software developers tend to leave the old feature around just long enough for serious users to adapt and clean up any loose ends on existing projects. After that, it’s gone for good.
In the case of web design and development, that trend often means that we can squeeze some extra life out of a feature for our existing sites, while using the latest solution for new projects. But the Classic editor may be a different ball of wax.
As you might have noticed, the road to get Gutenberg released with WordPress 5.0 was a bumpy one. There were a lot of ups and downs. Worst of all, an air of uncertainty left web professionals without a clear sense of how to approach both new and existing
This helpful walk-through goes over debugging WordPress core by tracking hooks, actions, and filters and knowing when to use and implement them.
Most WordPress developers are familiar with the concept of actions and filters. At the very heart of WordPress, these hooks allow developers to extend the functionality of WordPress in numerous ways. Whether you want to run a process when a post is saved, add a new section to the Edit User page, or modify the SQL used when querying the database, WordPress has hooks for (almost) everything. One thing I’ve noticed a lot, as a frequent user of the WordPress StackExchange, is that many developers don’t know where to start when trying to figure out which actions or hooks might be available to them. In this blog post, I want to help walk through the process of tracking down various hooks with examples of when you might want to use them and how to implement them.
Actions and Filters: What’s the Difference?
This is a very basic mistake I see often when helping people figure out their WordPress issues. They want to modify the Query with the pre_get_posts filter, but they can’t figure out why their code isn’t modifying anything. Well, let’s take a look at a basic example that sets the post_type parameter to “page”:
add_action( 'pre_get_posts', function(
Some tips and special considerations when dealing with content-heavy WP sites.
Eventually, every website will require a redesign. And each one presents its own set of unique challenges. Among the most challenging are large, content-heavy WordPress websites. Why? For starters, they often come with several different types of content to account for. Plus, their existing setup may not be as ideal today as it was when the site was originally built. And, if content is regularly added or changed, this throws yet another monkey wrench into the works.
All told, there is a lot to consider. That’s why it’s so important to plan ahead. While there will always be pain points, being prepared will make the process that much smoother.
So, before you tackle that next redesign project, let’s review some ways to get into the best position for success.
Review the Content Structure
First up, you’ll want to take a close look at how content is structured. Even if you were the one who originally built the website, it’s still a good idea to refresh your memory.
Things to look for include:
Parent and child pages
Taxonomies such as categories and tags
Custom post types
Once you have a better picture of how the existing content is set up, you
A Step By Step Guide To Converting A WordPress Shortcode To A Gutenberg Block - WordPress Form Builder
Since the new editor, AKA Gutenberg, is now in core, how are you handling shortcodes? Want to update your plugin or theme to use the new WordPress editor? - Easy step by step instructions on how to convert your shortcode into a block.
A Step By Step Guide To Converting A WordPress Shortcode To A Gutenberg Block - WordPress Form Builder
WordPress 5.0 was released at last year’s WordCamp US and introduces the new block-based “Gutenberg” editor. We’ve been super-excited about Gutenberg since then. Yes, @CalderaForms is the first plugin to be #Gutenberg-ready. We’re excited for the future of @WordPress, are you? https://t.co/X0HJqkzbGI
— Caldera WP (@CalderaWP) December 10, 2017
Now that WordPress 5.0 is out, everyone is excited about blocks, but one question I keep hearing is “what about my shortcodes?” That’s a good question. We wrote an article last year about how shortcodes work with Gutenberg.
We’ve been excited about Gutenberg for a long time. We were the first major plugin to add a block. One cool thing about our shortcode was it loaded a preview of our form in the post editor. I wanted to make sure our block did the same. Because we were so early, I had to write my own solution. For Caldera Forms 1.8, we’re using WordPress’ built-in solution for previewing blocks that are server-side rendered — blocks like our Caldera Forms block.
When I went to do this conversion for Caldera Forms, I could not find a great example outside of the official
Lately, I’ve been trying to become more familiar with design patterns. One thing I’ve realized along the way is that it’s not easy to recognize where a specific pattern might be useful. It usually comes down to having that light bulb moment where you suddenly say to yourself “Hey! This might be a good place to use a certain design pattern.” Define the problem.
With the rise of frameworks like React, we often hear about ‘application/component state.’ When the state is updated, components will re-render accordingly. In React, components are just a representation of what the user interface should look like.
So, let’s define the problem we are trying to solve: we need to be able to update multiple page elements when our application state
PHP 7.3 is knocking on our door and with it comes new useful features, functionalities, deprecations, and a good number of bug fixes. This release is definitely all about developers!
PHP 7.3 is knocking on our door and with it comes new useful features, functionalities, deprecations, and a good number of bug fixes. This release is all about web developers. The current Beta 2 version was released on August 16, coming perfectly on time with the PHP 7.3 timetable. You can download the current PHP 7.3 version for your development and testing, but keep in mind that, this shouldn’t currently be used in production environments.
In this post, we’ll provide an overview of the features and changes that we personally consider most relevant. But you can always check the full list of features, changes and bug fixes in PHP 7.3 upgrade notes and PHP 7.3 Requests For Comments.
What’s new in PHP with PHP 7.3?
In this post we’re covering the following PHP 7.3 changes:
Flexible Heredoc and Nowdoc Syntaxes
This is probably one of the most relevant improvements coming with PHP 7.3, and we think it deserves a little more attention. So, before diving into PHP 7.3 heredoc/nowdoc changes, we’ll provide a quick overview of this useful core feature. If you are already confident with nowdoc and heredoc, feel free to jump to the PHP 7.3 changes.
An overview of
If you want to display a Google map on your site, for example on your contact page, you need to generate an API key (a specific set of numbers and letters) using a Google account to ensure your map displays properly. This post explains how to obtain this API key and how to configure it so that it will work on your domain.
When first working with Google APIs to display a Google map on your site, it can be a daunting and tricky task to find out how to obtain the correct key and set everything up correctly. Not only that, Google made some significant changes to the process of generating them in June 2018. If a year or so ago, you had wrapped your head around how to do this, it’s all gone and changed! Whilst we are a fan of Google services, we are not madly keen on their documentation for this process. This post will guide you step by step through the process.
Step 1. Set up a Google account
The first thing you need a Google account. It’s likely you’ve already set up a Google account along the way (or several if you are me!). You may have a Gmail email account or an analytics account. If you don’t, it’s easy and quick to set up – all you need is an email address to get started.
To create an account, visit google.com and click the ‘Sign in’ button. Even if you don’t have an account yet this is the right first step.
From here you can login or create a new account.
2. Add billing details to your Google account
One of the key changes that came about in June
According to the webpack website:
Now you might be asking yourself, what is a dependency graph? In webpack, there are files specified as entry points. These entry points are at the top of the dependency graph. Any files required or imported from the entry files will be processed and bundled by webpack.
Discover what's the fastest Translation API between Google, Microsoft, Yandex & DeepL with our performance benchmark. We send tens of thousands of API requests to the top 4 Machine Translation API providers. Discover which one is the fastest.
At Weglot, one of our main features is to supply our customers with a first automatic translation layer when they have new content to translate. It’s a great way for them to not start their translation work from scratch and to save a lot of time. To provide those translations, we rely on several Translation providers and we send tens of thousands of API requests to those Translation providers on a daily basis. So the APIs performance is an everyday priority for us. As the quality of our service relies on those third parties applications for machine translation, it’s quite important for us to know the strengths and weaknesses of each of them.
Today, you can already find various articles and benchmarks online about the translation quality of those providers but not so much about performance, so let’s crunch numbers!
In order to ensure accurate results and fairness between the different third parties, we wrote a script that measures average response time under the same environment for each translation provider services, meaning that we would use the same language pair (obviously) and the same dictionary. The average response time is computed out of 100 requests.