What is WordPress? It began as a simple CMS for building a blog, and it has evolved over the years into a complex ecosystem of tools and resources.
WordPress can power ecommerce sites, interactive courses, art projects, and of course, it powers one or two blogs. Depending on who you ask, WordPress powers between 35% and 40% of the entire web; that makes it one of the most important technologies of the web era. Best of all, it’s free and open-source, so if you’re new to web design, WordPress is a great place to get started.
We’ve put together this simple infographic with all the facts you need to know about WordPress 2021.
An interesting conversation came up at work the other day: Should we use the CSS float property now that we have CSS Grid and Flexbox?
The short answer
No! Well, mostly. I’d only use it today for wrapping text around images, though and I’d avoid using float entirely for layouts.
The longer, more annoying answer
Before flexbox and grid, we had to use the CSS float property to make grids and layouts. In fact, it was the first thing I learned about web design. On one hot summer afternoon I cracked open a copy of Designing with Web Standards by Jeffrey Zeldman and then moved a tiny red div with float: right. It was magic. There was power in the float.
It was so easy to move something around on the screen that I now wonder how many designers fell in love with the web simply because of how easy it is to use move things around like that.
But using float to build complex layouts was always a hack: it was only really designed to let text wrap around an image.
img {
width: 150px;
float: left;
}
CodePen Embed Fallback
The problems with float begin when we try to build giant layouts and magazine-style grids. But that’s what we had to do since there were no alternatives back then like we do today.
One problem with the float property is that you’d have to wrap floated elements with something called a clearfix that looked like this:
The clearfix, for those unaware, is a CSS hack that solves a persistent bug that occurs when two floated elements are stacked next to each other. When elements are aligned this way, the parent container ends up with a height of 0, and it can easily wreak havoc on a layout. All you might be trying to do is position a sidebar to the left of your main content block, but the result would be two elements that overlap and collapse on each other. To complicate things further, the bug is inconsistent across browsers. The clearfix was invented to solve all that.
Things began to slowly change after that. Back in 2017, Rachel Andrew explained how browsers can handle the clearfix problem without any hacks at all. All we need is the following CSS to make the same fix:
.container {
display: flow-root;
}
The odd thing is that I didn’t know the flow-root value existed until about three minutes before I typed that. But I guess this sort of defends the argument I’m about to make here: with CSS Grid and Flexbox we don’t really need float at all. The property was really designed to do one thing: let text wrap around images. But now, with grid and flexbox, we have wonderful powers that can do all the heavy lifting for real layouts.
Back to the argument I was having at work. Some folks said that we should go back and delete all the instances of float in our codebase because it’s old code and we can easily replace it with flexbox or grid. But this is where I’d say, Whoa! hold up a sec. I don’t think having the float property in a few places in our codebase is doing that much harm at all — this isn’t radioactive code that’s causing problems.
So should we be using CSS float for anything besides letting text wrap around text? Nope. But should we all go out and immediately purge the web of CSS float declarations because it’s not pure and not the “correct” way of doing things? Nope again.
The nifty thing about the web is that old code shouldn’t break things. Just ask Chris. A website that isn’t using the fanciest CSS properties or the coolest tricks isn’t useless or bad. We’ve simply replaced float with alternatives that are better. I think it’s a good lesson here that these CSS properties are likely going to stick around forever because they still have applicable use cases in modern web design.
Maximiliano Firtman has a look at PWAs this year, including trying to get a bead on how widespread they are:
At the end of 2020, approximately 1% of websites included a Service Worker, and 2.2% had an installable Web App Manifest file. Remember that some platforms -such as Safari on iOS or Chrome on Android- do not require a Service Worker to have a standalone experience after installation. We can assume that 2.2% of websites are installable, and 1% may pass the PWA criteria on Android, 71% of which offer some offline experience.
That data is from the HTTP Archive, which looked at 7.5 million websites. So 1% might seem like a small number, but that’s lots of sites with PWA tech on them, and 170% year-over-year growth. Those are just the minimum requirements, though. I’m sure fully embracing PWA-ness (e.g. real offline usage) is a tiny fraction of that. Maximiliano has lots of more detailed data, so be sure to dig into the article if you’re interested in the nuance.
Anecdotally, I’d say PWAs fell out of general conversation last year. I don’t think anybody is exactly against the technologies that make them up, but they aren’t embracing them either. My guess? Everyone is scared of Service Workers. I’m scared of Service Workers. They do scary things, like aggressively hold onto cache. I think a whole dev team really needs to understand them and embrace them into their workflow and build process for them to be effective. Generally speaking, we just aren’t there yet.
WordPress core is making the jump from jQuery 1.12.4 to jQuery 3.5.1! This is a big deal for lots of reasons — like modern features, better DX, and security improvements to name a few. Right now, the plan is to release the update in WordPress 5.7, which is slated to release on March 9. ?
WordPress is notorious for its backwards compatibility and you could say this change is a relic of that philosophy. A line has been drawn in the sand when it comes to jQuery, and 1.x ain’t a part of plans moving forward. But it also represents a breaking change, and that’s sorta rare in the WordPress world. Because WordPress ships with jQuery installed, many developers call that version of it rather than re-installing it in another location. That includes lots of theme and plugin developers, all of whom now need to make sure their code is compatible with jQuery 3.x.
Not doing so could result in lots on borked sites. But, hey, we have about a month left to work on it, right?
The change has actually been in the works for some time. The work began in WordPress 5.5, and 5.7 is technically the third of three phases. WordPress 5.6 is where the Core Team bumped jQuery up to version 3.5.1 and updated jQuery Migrate to help developers revert back to legacy jQuery, if needed. In other words, this has been a super methodical approach. The Core Team deserves a lot of kudos for that, including all of the communications that have gone out about the change.
I wrote something up about the transition a couple of weeks ago, including a sort of how-to for testing things in advance, and troubleshooting issues after the fact. It’s aimed at beginners, but maybe you’ll find it helpful too. Make WordPress Support has its own thorough article as well, and it calls out a plugin that the WordPress team made just for this transition. It’s pretty sweet: it can roll your site back to jQuery1.x automatically if it detects a fail. It also documents those fails and sends notifications when they happen.
The key is to start testing now in WordPress 5.6. The plan is to disable jQuery Migrate in WordPress 5.7, so waiting for that release is too late. If you do wait that long and find issues, your best path forward is likely to roll back to 5.6 anyway to take advantage of jQuery Migrate and the helper plugin.
GraphQL is a query language and server-side runtime environment for building APIs. It can also be considered as the syntax that you write in order to describe the kind of data you want from APIs. What this means for you as a backend developer is that with GraphQL, you are able to expose a single endpoint on your server to handle GraphQL queries from client applications, as opposed to the many endpoints you’d need to create to handle specific kinds of requests with REST and turn serve data from those endpoints.
If a client needs new data that is not already provisioned. You’d need to create new endpoints for it and update the API docs. GraphQL makes it possible to send queries to a single endpoint, these queries are then passed on to the server to be handled by the server’s predefined resolver functions and the requested information can be provided over the network.
Running Flask server
Flask is a minimalist framework for building Python servers. I always use Flask to expose my GraphQL API to serve my machine learning models. Requests from client applications are then forwarded by the GraphQL gateway. Overall, microservice architecture allows us to use the best technology for the right job and it allows us to use advanced patterns like schema federation.
In this article, we will start small with the implementation of the so-called Levenshetein distance. We will use the well-known NLTK library and expose the Levenshtein distance functionality with the GraphQL API. In this article, i assume that you are familiar with basic GraphQL concepts like BUILDING GraphQL mutations.
Note: We will be working with the free and open source example repository with the following:
In the projects, Pipenv was used for managing the python dependencies. If you are located in the project folder. We can create our virtual environment with this:
…and install dependencies from Pipfile.
We usually define a couple of script aliases in our Pipfile to ease our development workflow.
It allows us to run our dev environment easily with a command aliases as follows:
The flask server should be then exposed by default at port 5000. You can immediately move on to the GraphQL Playground, which serves as the IDE for the live documentation and query execution for GraphQL servers. GraphQL playground uses the so-called GraphQL introspection for fetching information about our GraphQL types. The following code initializes our Flask server:
It is a good practice to use the WSGI server when running a production environment. Therefore, we have to set-up a script alias for the gunicorn with:
Levenshtein distance (edit distance)
The levenshtein distance, also known as edit distance, is a string metric. It is defined as the minimum number of single-character edits needed to change a one character sequence a to another one b. If we denote the length of such sequences |a| and |b| respectively, we get the following:
Where
1(ai?bj) is the distance between the first icharacaters of a and the first jcharacter of b. For more on the theoretical background, feel free to check out the Wiki.
In practice, let’s say that someone misspelt ‘machine learning’ and wrote ‘machinlt learning’. We would need to make the following edits:
Edit
Edit type
Word state
0
–
Machinlt lerning
1
Substitution
Machinet lerning
2
Deletion
Machine lerning
3
Insertion
Machine learning
For these two strings, we get a Levenshtein distance equal to 3. The levenshtein distance has many applications, such as spell checkers, correction system for optical character recognition, or similarity calculations.
Building a Graphql server with graphene in Python
We will build the following schema in our article:
Each GraphQL schema is required to have at least one query. We usually define our first query in order to health check our microservice. The query can be called like this:
query {
healthcheck
}
However, the main function of our schema is to enable us to calculate the Levenshtien distance. We will use variables to pass dynamic parameters in the following GraphQL document:
We have defined our schema so far in SDL format. In the python ecosystem, however, we do not have libraries like graphql-tools, so we need to define our schema with the code-first approach. The schema is defined as follows using the Graphene library:
We have followed the best practices for overall schema and mutations. Our input object type is written in Graphene as follows:
Each time, we execute our mutation in GraphQL playground:
With the following variables:
{
"input": {
"s1": "test1",
"s2": "test2"
}
}
We obtain the Levenshtein distance between our two input strings. For our simple example of strings test1 and test2, we get 1. We can leverage the well-known NLTK library for natural language processing (NLP). The following code is executed from the resolver:
It is also straightforward to implement the Levenshtein distance by ourselves using, for example, an iterative matrix, but I would suggest to not reinvent the wheel and use the default NLTK functions.
Serverless GraphQL APIs with Fauna
First off some introductions, before we jump right in. It’s only fair that I give Fauna a proper introduction as it is about to make our lives a whole lot easier.
Fauna is a serverless database service, that handles all optimization and maintenance tasks so that developers don’t have to bother about them and can focus on developing their apps and shipping to market faster.
Again, serverless doesn’t actually mean “NO SERVERS” but to simply put it: what serverless means is that you can get things working without necessarily having to set things up from scratch. Some apps that use serverless concepts don’t have a backend service written from scratch, they employ the use of cloud functions which are technically scripts written on cloud platforms to handle necessary tasks like login, registration, serving data etc.
Where does Fauna fit into all of this? When we build servers we need to provision our server with a database, and when we do that it’s usually a running instance of our database. With serverless technology like Fauna, we can shift that workload to the cloud and focus on actually writing our auth systems, implementing business logic for our app. Fauna also manages things like, maintenance and scaling which usually calls for concern with systems that use conventional databases.
If you are interested in getting more info about Fauna and it’s features, check the Fauna docs. Let’s get started with building our GraphQL API the serverless way with the GraphQL.
Login to your Fauna account once you have created an account with them. Once on the dashboard, you should see a button to create a new database, click on that and you should see a little form to fill in the name of the database, that resembles the ones below:
I call mine “graphqlbyexample” but you can call yours anything you wish. Please, ignore the pre-populate with demo data option we don’t need that for this demo. Click “Save” and you should be brought to a new screen as shown below:
Adding a GraphQL Schema to Fauna
In order to get our GraphQL server up and running, Fauna allows us to upload our own graphQL schema, on the page we are currently on, you should see a GraphQL options; select that and it will prompt you to upload a schema file. This file usually contains raw GraphQL schema and is saved with either the .gql or .graphql file extension. Let’s create our schema and upload it to Fauna to spin up our server.
Create a new file anywhere you like. I’m creating it in the same directory as our previous app, because it has no impact on it. I’m calling it schema.gql and we will add the following to it:
Here, we simply define our data types in tandem to our two tables (Notes, and user). Save this and go back to that page to upload this schema.gql that we just created. Once that is done, Fauna processes it and takes us to a new page — our GraphQL API playground.
We have literally created a graphql server by simply uploading that really simple schema to Fauna and to highlight some of the really cool feats that Fauna has, observe:
Fauna automatically generates collections for us, if you notice, we did not create any collection(translates to Tables, if you are only familiar with relational databases). Fauna is a NoSQL database and collections are technically the same as tables, and documents as to rows in tables. If we go to the collections options and click on that we had see the tables that were auto-generated on our behalf, courtesy of the schema file that we uploaded.
Fauna automatically creates indexes on our behalf: head over to the indexes option and see what indexes have been created on behalf of the API. Fauna is a document-oriented database and does not have primary keys or foreign-keys as you have in relational databases for search and index purposes, instead, we create indexes in Fauna to help with data retrieval.
Fauna automatically generates graphql queries and mutations as well as API Docs on our behalf: This is one of my personal favorites and I can’t seem to get over just how efficient Fauna does this. Fauna is able to intelligently generate some queries that it thinks you might want in your newly created API. Head over back to the GraphQL option and click on the “Docs” tab to open up the Docs on the playground.
As you can see two queries and a handful of mutations already auto-generated (even though we did nit add them to our schema file), you can click on each one in the docs to see the details.
Testing our server
Let’s test out some of these queries and mutations from the playground, we also use our server outside of the playground (by the way, it is a fully functional GraphQL server).
Testing from the Playground
We will test our first off by creating a new user, with the predefined createUser mutations as follows:
If we go to the collections options and choose User, we should have our newly created entry(document aka row) in our User collections.
Let’s create a new note and associate it with a user as the author via it’s document ref id, which is a special ID generated by Fauna for all documents for the sake of references like this much like a key in relational tables. To find the ID for the user we just created simply navigate to the collection and from the list of documents you should see the option(a copy Icon)to copy Ref ID:
Once you have this you can create a new note and associate is as follows:
Let’s make a query this time, this time to get data from the database. Currently, we can fetch users by ID or fetch a note by it’s ID. Let’s see that in action:
You must have been thinking it, what if we wanted to fetch info of all users, currently, we can’t do that because Fauna did not generate that automatically for us, but we can update our schema so let’s add our custom query to our schema.gql file, as follows. Note that this is an update to the file so don’t clear everything in the file out just add this to it:
Once you have added this, save the file and click on the update schema option on the playground to upload the file again, it should take a few seconds to update, once it’s done we will be able to use our newly created query, as follows:
Don’t forget that as opposed to having all the info about users served (namely: name, email, password) we can choose what fields we want because it’s a GraphQL and not just that. It’s Fauna’s GraphQL so feel free to specify more fields if you want.
Testing from without the playground – Using python (requests library)
Now that we’ve seen that our API works from the playground lets see how we can actually use this from an application outside the playground environment, using python’s request library so if you don’t have it installed kindly install it using pip as follows:
pip install requests
Before we write any code we need to get our API key from Fauna which is what will help us communicate with our API from outside the playground. Head over to security on your dashboard and on the keys tab select the option to create a new key, it should bring up a form like this:
Leave the database option as the current one, change the role of the key from admin to the server and then save. It’ll generate for you a new key secret that you must copy and save somewhere safe, as an environment variable most probably.
For this I’m going to create a simple script to demonstrate, so add a new file call it whatever you wish — I’m calling mine test.py to your current working directory or anywhere you wish. In this file we’ll add the following:
Here we add a couple of imports, including the requests library which we use to send the requests, as well as the os module used here to load our environment variables which is where I stored the Fauna secret key we got from the previous step.
Note the URL where the request is to be sent, this is gotten from the Fauna GraphQL playground here:
Next, we create a query which is to be sent this example shows a simple fetch query to find a user by id (which is one of the automatically generated queries from Fauna), we then retrieve the key from the environment variable and store it in a variable called a token, and create a dictionary to represent out headers, this is, after all, an HTTP request so we can set headers here, and in fact, we have to because Fauna will look for our secret key from the headers of our request.
The concluding part of the code features how we use the request library to create the request, and is shown as follows:
We create a request object and check to see if the request went through via its status_code and print the response from the server if it went well otherwise we print an error message lets run test.py and see what it returns.
Conclusion
In this article, we covered creating GraphQL servers from scratch and looked at creating servers right from Fauna without having to do much work, we also saw some of the awesome, cool perks that come with using the serverless system that Fauna provides, we went on to further see how we could test our servers and validate that they work.
Hopefully, this was worth your time, and taught you a thing or two about GraphQL, Serverless, Fauna, and Flask and text analytics. To learn more about Fauna, you can also sign up for a free account and try it out yourself!
This article is brought to you by 4Kdownload.com, a suite of video tools that help you make the most of YouTube, Instagram, Vimeo, and many more popular resources.
YouTube isn’t just for videos of cats snowboarding; it’s also a treasure trove of design tips, freebies, how-tos, career advice, and all-around creative inspiration.
Whether you’re a seasoned design veteran or just taking the first steps along a creative career, there are thousands of videos that will guide your path.
Today, we’ve collected ten of the best YouTube channels for designers, where you’ll find all the guidance you’ll ever want. Enjoy!
AIGAdesign
The first stop for any aspiring designer or grizzled veteran should be AIGAdesign, the official YouTube channel for AIGA, the American Institute of Graphic Arts.
This channel focuses on a huge range of issues that affect designers. You’ll find insightful and high-production-value videos on branding, the design business, the creative process, and the institute’s numerous initiatives.
?
Adobe
Adobe products are still the go-to tool for most designers, and no list of this type would be complete without a nod to the substantial resources that Adobe plows into its YouTube channel.
Review highlights from MAX, Adobe’s annual conference, learn advanced techniques in Creative Cloud apps like Illustrator and Photoshop, and get a sneak peek at upcoming Adobe products.
?
Google Design
Google is one of the most influential companies on the web, and not just for SEO. Google’s Design is the megacorp’s creative branch. In addition to releasing design resources like Material Design, they also produce a lot of content on their own YouTube channel to benefit emerging designers.
Look back at Google’s I/O conference sessions, follow guides on how to get the most out of Google resources, and get tips on creativity.
?
The Futur
The Futur is an online education platform that happens to be streaming via YouTube. It’s a positive, feel-good channel that’s designed to help you make the most of your career.
You’ll find inspiring videos on building a brand, setting up a studio, coping with client demands, and everything else you need to be a professional designer.
?
Envato Tuts+
Envato Tuts+ is a YouTube channel that concentrates on the practical side of being a designer with plenty of hands-on guides to different applications.
You’ll also find some excellent videos explaining the fundamentals of topics like variable fonts and animation.
?
Creatnprocess
If you’re already proficient with Adobe Creative Cloud, and you’re looking to push your limits a little, then Creatnprocess will teach you more advanced topics.
It’s a great place to learn the more complex aspects of image manipulation, and there are lots of logo design tutorials.
?
Sketch Together
If you’re a fan of Pablo Stanley’s design style, then you’ll love his Sketch Together YouTube channel. He has tons of design tutorials, walk-throughs and project case studies, and in-depth discussions with guest designers.
In case the name wasn’t enough of a clue, Sketch Together also has an awesome collection of Sketch videos.
?
Martina Flor
Martina Flor is an amazing letterer and typeface designer from Berlin, by way of Argentina. As well as running her own studio, she’s an author and educator.
Martina’s YouTube channel is a must-watch for anyone who loves typography and lettering. Her videos include her secrets on how to draw letters.
?
Pixel & Bracket
Pixel & Bracket is a YouTube channel run by Spencer, a designer from Indianapolis.
You’ll find tons of great Creative Cloud tutorials that are easy to follow. You’ll also find a few videos about Spencer’s experience as a designer and a sprinkling of freebies he’s found on market places.
?
Will Paterson
Will Paterson is a logo designer whose YouTube channel critiques famous logos, provides product reviews, and offers invaluable branding design tips.
Will’s got some really original ideas for freelancers, and he’s generous with both his advice and his enthusiasm.
?
Save Your Videos for Watching Offline
With so many awesome videos available, you could watch them all day long and still only scratch the surface.
The best solution is to subscribe to the channels you like the look of, and then download a few videos with a free app like 4K Video Downloader so you can watch them back whenever you like.
With so much to choose from and a seemingly endless lockdown still in effect, now’s the perfect time to learn a new skill, develop your career, or sit back and enjoy some design banter.
This article is brought to you by 4Kdownload.com, a suite of video tools that help you make the most of YouTube, Instagram, Vimeo, and many more popular resources.
What if an had within it another of the exact same source? Inception, as they say. Baptise Crespy does this all-important research in the name of art and science.
Turns out browsers are smart enough to not allow this infinite looping to occur (and likely crash your browser/computer). They strip the content after the 2nd nest. But! If you change the URL of the src to be unique (but still essentially serve the same document), it works. Adding some random colors and animations and things get weird really fast.
Removing media support from HTML video was a mistake. It means that for every video we embed in HTML, we’re stuck with the choice of serving source files that are potentially too large or small for many users’ devices (resulting in poor performance, wasteful data consumption, and even sub-optimal quality on larger screens), or resorting to more complicated server-side or scripted or third-party solutions to deliver a correct size.
I remember when responsive images were just starting to come out. One way to explain it was to say it’s like in that you can have multiple elements inside which (in supporting browsers) allowed you to specify attributes like type (e.g. video format) and media (e.g. screen size). But then…
Despite being implemented in multiple browsers, the feature was removed from browsers and the HTML specification, without any proposed replacement for the functionality it once provided. One exception is the feature was never removed from Webkit, so it still works in Safari browsers, which is great.
I don’t remember that. That feels like a big WTF moment (some background). I think of the web as being tremendous at backwards compatibility. It’s a rare day when we just yank stuff, and even more rare is a yanking with no alternative whatsoever.
So now with responsive images being a success (it’s a success, right? I can’t imagine how incredibly much bandwidth it has saved the world)… can’t we… put it back?
When I have an immediate need for this, I always think of Cloudinary, because I can alter the size and format of video by changing the URL. Like here’s a video URL where the video codec is automatically determined and the size is forced down to 400px:
What’s so cool about :focus-visible? It’s all about the blue focus ring that displays around elements that are in focus. It’s sort of a happy medium between loving the outline for accessibility purposes (gotta know what element is selected when tabbing on a keyboard) but not-really-loving how it looks (gotta have everything follow brand).
The strategy has largely been an all-or-nothing choice between using a custom outline when any element is in :focus (great, but that means for both keyboard tabbing and mouse clicks) or ditching the outline altogether (not great, like ever). :focus-visible accomplishes the same thing as :focus, but uses a browser’s knowledge of user inputs (or heuristics) to determine whether the focus is coming from a keyboard or a mouse.
(Are a browser’s heuristics perfect at determining the input? That depends. Things get murky once we start factoring in things like touch interactions.)
That means, we get to remove the default focus ring (yay!) for the right types of interactions (double yay!) and display our own custom styles while we’re at it (triple yay!). Allow me to pluck Andy Adams’ fine example straight from our almanac. Note that :focus-visible cannot remove the focus ring like :focus can, so the two are used together:
Chrome implemented :focus-visibleback in 2018. Firefox had it’s own prefixed version, :-moz-focusring, prior to this implementation. Safari? Go vote for the feature!
I always appreciate someone looking into and re-evaluating the best practices of something that literally every website needs and has a complex set of requirements. Andrey Sitnik has done that here with favicons.
It was good timing to do this here on CSS-Tricks, so I tried following the advice to the letter, and it’s working great so far. I think I got fed up at how complex it was at some point that I went ultra-minimalist and only had favicon.ico file. Now I’ve got all of the above in place.
Where I differed…
I don’t have GIMP or Inkscape installed, which can export .ico format, so I used this favicon generator (I fed it my “main” SVG”) just for that one icon.
I found Figma helpful for resizing frames and exporting the right sizes.
I used ImageOptim for optimizing all the images.
I was nervous about adding a “manifest” because I don’t have any other PWA-like steps in place and it feels like an extra web request for little value. But I did it anyway.
I have a theme color () because I was told it was a nice touch. Feels related.
