PHP | The Blog Pros

November 9, 2023

WordPress Playground: From 5-Minute Install To Instant Spin-Up

Many things have changed in WordPress over the years, but installation has largely remained the same: download WordPress, drop it on a server, create a database, sprinkle in some configuration, and presto, we have a WordPress site. This process was once lovingly referred to as the “famous five-minute install,” although that moniker seems to have faded with time, particularly as many hosting providers offer a more streamlined experience.

But what if WordPress didn’t require any setup at all? As in, you tap a link, and WordPress spins up a site for you right there, on demand? That’s probably difficult to imagine, considering WordPress runs on top of PHP, MySQL databases, and Apache. It’s not the most portable system.

That’s the aim of WordPress Playground, which got its first public boost when Matt Mullenweg introduced it during State of Word 2022.

Notice how the URL is a subdomain of a TasteWP-related top-level domain: hangingpurpose.s1-tastewp.com. It generates an instance on the multi-site network and establishes a URL for it based on a randomized naming system.

There’s a giant countdown timer on the screen that indicates when the site is scheduled to expire. That makes sense, right? Allowing anyone and everyone to create a site on the spot without so much as a login could become taxing on the server, so allowing sites to self-destruct on a schedule is likely as much to do with self-preservation as it does economics.

Speaking of economics, the countdown timer is immediately followed by a call to action to upgrade, which buys you permanence, extra server space, and customer support.

Without upgrading, though, you are only allowed two free instant sites. But if you create an account and log into TasteWP, then you can create up to six test sites on a free pricing tier.

That’s a look at the “quick” onboarding, but TasteWP does indeed have a more robust way to spin up a WordPress testing site with a set of advanced configurations, including which WordPress version to use with which version of PHP, settings you might normally define in wp-config.php, and options for adding specific themes and plugins.

So, how does that compare to WordPress Playground? Perhaps the greatest difference is that a TasteWP site is connected to the internet. It’s not a WordPress simulation, but an actual instance with a URL you can link up and share with others… as long as the site hasn’t expired. That could very well be enough of a differentiation to warrant more players in this space, even with WordPress Playground hanging around.

I wanted to give you a sense of what’s already offered before actually unboxing WordPress Playground. Now that we know what else is out there let’s turn our attention back to Playground and explore it.

Starting Up WordPress Playground

One of the first interesting things about WordPress Playground is that it is available in not just one but several places. I wouldn’t liken it completely to a service like TasteWP, where you create an account to create and manage WordPress instances. It’s more like a developer tool, one that you can reach for when testing your work in a WordPress environment.

You can simply hit the playground.wordpress.net URL in your browser to launch a new site on the spot. Or, you can launch an instance from the command line. Perhaps you prefer to use the official Chrome extension instead. Whatever the case, let’s look at those options.

1. Using The WordPress Playground URL

This is the most straightforward way to get a WordPress Playground instance up and running. That’s because all you do is visit the playground.wordpress.net address in the browser, and a WordPress site is created immediately.

This is exactly how the WordPress Playground demo works, prompting you to click a button to open a new WordPress site. In fact, try clicking the following button to create one now.

Create A WordPress Site

If you want to use a specific version of WordPress and PHP in your Playground, all it takes is adding a couple of parameters to the URL. For example, we can instruct Playground to run WordPress 6.2 on PHP 8.2 with the following URL:

https://playground.wordpress.net/?php=8.2&wp=6.2

You can even try out the developmental versions of WordPress using Playground by using the following parameter:

https://playground.wordpress.net/?wp=beta

2. Using The GitHub Repository

True to the WordPress ethos, WordPress Playground is very much an open-source project. The repo is available over at GitHub, and we can pull it into a local environment and use WordPress Playground right from a terminal.

First, let’s clone the repository from the command line:

git clone https://github.com/WordPress/wordpress-playground.git

There is a slightly faster alternative that fetches just the latest revision:

git clone -b trunk --single-branch --depth 1 git@github.com:WordPress/wordpress-playground.git

Now that we have the WordPress Playground package in our local environment, we can formally install it:

cd wordpress-playground
npm install
npm run dev

Once the local server is running, we should get a URL from the terminal that we can use to access the new Playground instance, likely pointed to http://localhost:5400/website-server/.

We are also able to set which versions of WordPress and PHP to use in the virtual environment by adding a couple of instructions to the command. For example, this command triggers a new WordPress 5.9 instance running on PHP 7.4:

wp-now start --wp=5.9 --php=7.4

3. Using `wp-now` In The Command Line

An even quicker way to get Playground running from the command line is to globally install the wp-now CLI tool:

npm install -g @wp-now/wp-now

This way, we can create a new Playground instance anytime you want with a single command:

wp-now start

Be sure that you’re using Node 18 or higher. Otherwise, you’re likely to bump into some errors. Once the command executes, however, the browser will automatically open a new tab pointing to the new instance. You’re already signed into WordPress and everything!

We can configure the environment just as we could with the npm package:

wp-now start --wp=5.9 --php=7.4

A neat thing about this method is that there are several different “modes” you can run this in, and which one you use depends on the directory you’re in when running the command. For example, if you run the command from a directory that already contains WordPress, then Playground will automatically recognize that and run the directory as a full WordPress installation. Or, it’s possible to execute the command from a directory that contains nothing but an index.php file, and Playground will start the server and run requests through that file.

There are other options, including modes for theme, plugin, wp-content, and wordpress-develop, that are worth checking out in the documentation.

4. Using The Visual Studio Code Extension

WordPress Playground is also available as a Visual Studio Code extension. It provides a nice one-click process to launch a local WordPress site.

Installing the extension adds a WordPress icon to the sidebar menu that, when clicked, opens a panel for launching a new WordPress Playground site.

Open a project folder, click the “Start WordPress Server,” and the Playground extension boots up a new site on the spot. The extension also provides server details, including the local URL, the mode it’s in, and settings to change which versions of WordPress and PHP are in use.

One thing I noticed while poking at the instance is that it automatically installs and activates the SQLite Database Integration plugin. Obviously, that’s a required component for things to work, but I thought it was worth pointing out that the installation does indeed include at least one pre-installed plugin right out of the gate.

5. Using A Chrome Extension To Preview Themes & Plugins

Have you ever found yourself perusing the WordPress Theme Directory and wanting to take a particular theme out for a test drive? There’s already a “Preview” button baked right into the directory to do exactly that.

That’s nice, as it opens up the theme in a frame that looks a lot like the classic WordPress Customizer.

But how cool would it be to really open up the theme and see what it is like to do actual tasks with it in the WordPress admin, such as creating a post, editing a page, or exploring its block patterns?

That is what the “Open in WordPress Playground” extension for Chrome can do. It literally adds a button to “Preview” a theme in a fresh WordPress Playground instance that, when clicked, allows you to interact with the theme in a real WordPress environment.

I tried out the extension, and it worked as described, and not only that, but it works with the WordPress Plugin Directory as well. In other words, it’s now possible to try a new plugin on the spot without having to install, activate, and test it yourself in some sandbox or, worse, your live or staging WordPress environments.

This is a potential game-changer as far as lowering the barrier to entry for using WordPress and for theme and plugin developers offering a convenient way to provide users with a demo experience. I can easily imagine a future where paid commercial plugins adopt a similar user experience to help reduce refunds from customers merely wanting to try a plugin before formally committing to it.

The extension is available free of charge in the Chrome Web Store, but you can check out the source code in its GitHub repository as well. While we’re on it, it’s worth noting that this is a third-party extension rather than an official WordPress or Automattic release.

The Default Playground Site

No matter which Playground method you use, the instances that spin up are nearly identical. For example, all of the methods we covered have the WordPress Twenty Twenty-Three theme installed and activated by default. That makes a lot of sense: a standard WordPress installation does the same.

Similarly, all of the instances we covered make use of the SQLite Database Integration plugin developed by the WordPress Performance Team. This also makes sense: we need the plugin to establish a database. It also sounds like from the plugin description that the intent is to eventually integrate the plugin into WordPress Core, so perhaps we’ll eventually see zero plugins in a default Playground instance at some point.

There are a few differences between instances. They’re not massive, but worth calling out so you know what you are activating or have available when using a particular method to create a WordPress instance. The following table breaks down the current components included in each method at the time of this writing:

Method	WordPress Version	PHP Version	Themes	Plugins
WordPress Playground website	6.3.2	8.0	Twenty Twenty-Three (active)	SQLite Database Integration (active)
GitHub repo	6.3.2	8.0	Twenty Twenty-Three (active)	SQLite Database Integration (active)
wp-now package	6.3.2	8.0.10-dev	Twenty Twenty-Three (active) Twenty Twenty-Two Twenty Twenty-One	Akismet Hello Dolly SQLite Database Integration (active)
VS Code extension	6.3.2	7.4	Twenty Twenty-Three (active) Twenty Twenty-Two Twenty Twenty-One	Akismet Hello Dolly SQLite Database Integration (active)
Chrome extension	6.3.2	8.0	Twenty Twenty-Three (active)	SQLite Database Integration (active)

And, of course, any other differences would come from how you configure an instance. For example, if you run the wp-now package on the command line when you’re in a directory with WordPress and several themes and plugins installed, then those themes and plugins will be available to activate and use. Similarly, using the Chrome Extension on any WordPress Theme Directory page or Plugin Directory page will install that particular theme or plugin.

Installing Themes, Plugins, and Block Patterns

In a standard WordPress installation, you might log into the WordPress admin, navigate to Appearance → Themes, and install a new theme straight from the WordPress Theme Directory. That’s because your site has a web connection and is able to pull things in from WordPress.org. Since a WordPress Playground instance from the WordPress Playground website (which is essentially the same as the Chrome extension) is not technically connected to the internet, there is no way to install plugins and themes to it.

If you want the same sort of point-and-click experience in your Playground site that you would get in a standard WordPress installation, then go with the GitHub repo, the wp-now package, or the VS Code extension. Each of these is indeed connected to the internet and is able to install themes and plugins directly from the WordPress admin.

You may notice a note about using the Query API to install a theme or plugin to a WordPress Playground instance that is disconnected from the web:

“Playground does not yet support connecting to the themes directory yet. You can still upload a theme or install it using the Query API (e.g. ?theme=pendant).”

That’s right! We’re still able to load in whatever theme we want by passing the theme’s slug into the Playground URL used to generate the site. For example,

https://playground.wordpress.net/?theme=ollie

The same goes for plugins:

https://playground.wordpress.net/?plugin=jetpack

And if we want to bundle multiple plugins, we can pass in each plugin as a separate parameter chain with an ampersand (&) in the URL:

https://playground.wordpress.net/plugin=jetpack&plugin=woocommerce

It does not appear that we can do the same thing with themes. If you’re testing several themes in a single instance, then it’s probably best to use the wp-now package or the VS Code extension when pointing at a directory that already includes those themes.

What about block patterns, you ask? We only get two pre-defined patterns in a default WordPress Playground instance created on Playground’s site: Posts and Call to Action.

That’s because block patterns, too, are served to the WordPress admin from an internet connection. We get a much wider selection of options when creating an instance using any of the methods that establish a local host connection.

There appears to be no way, unfortunately, to import patterns with the Query API like we can for themes and plugins. The best way to bring in a new pattern, it seems, is to either bundle them in the theme you are using (or pointing to) or manually navigate to the Block Pattern Directory and use the “Copy” option to paste a pattern into the page or post you are testing in Playground.

Importing & Exporting Playgrounds

The transience of a WordPress Playground instance is its appeal. The site practically evaporates into thin air with the trigger of a page refresh. But what if you actually want to preserve an instance? Perhaps you need to come back to your work later. Or maybe you’re working on a visual tweak and want to demo it for your team. Playground instances can indeed be exported and even imported into other instances.

Open up a new WordPress site over at the playground.wordpress.net and locate the Upload and Download icons at the top-right corner of the frame.

No worries, this is not a step-by-step tutorial on how to click buttons. The only thing you really need to know is that these buttons are only available in instances created at the WordPress Playground site or when using the Chrome Extension to preview themes and plugins at WordPress.org.

What’s more interesting is what we get when exporting an instance. We get a ZIP file — wordpress-playground.zip to be exact — as you might expect. Extract that, and what we have is the entire website, including the full WordPress installation. It resembles any other standard WordPress project with a wp-content directory that contains the source files for the installed themes and plugins, as well as media library uploads.

The only difference I could spot between this WordPress Playground package and a standard project is that Playground provides the SQLite database in the export, also conveniently located in the wp-content directory.

This is a complete WordPress project. Now that we have it and have confirmed it has everything we would expect a WordPress site to have, we can use Playground’s importing feature to replicate the exported site in a brand-new WordPress Playground instance. Click the Upload icon in the frame of the new instance, then follow the prompts to upload the ZIP file we downloaded from the original instance.

You can probably guess what comes next. If we can export a complete WordPress site with Playground, we can not only import that site into a new Playground instance but import it to a hosting provider as well.

In other words, it’s possible to use Playground as a testing ground for development and then ship it to a production or staging environment when ready. Similarly, the exported files can be committed to a GitHub repo where your production files are, and that triggers a fresh build in production. However you choose to roll!

Sharing Playgrounds

There are clear benefits to being able to import and export Playground sites. WordPress has never been the more portable system. You know that if you’ve migrated WordPress sites and data. But when WordPress is able to move around as freely as it does with Playground, it opens up new possibilities for how we share work.

Sharing With The Query API

We’ve been using the Query API in many examples. It’s extremely convenient in that you append parameters on the WordPress Playground site, hit the URL, and a site spins up with everything specified.

The WordPress Playground site is hosted, so sharing a specific configuration of a Playground site only requires you to share a URL with the site’s configurations appended as parameters. For example. this link shares the Blue Note theme configured with the Gutenberg plugin:

https://playground.wordpress.net/?plugin=gutenberg&theme=blue-note

We can do a little more than that, like link directly to the post editor:

https://playground.wordpress.net/?plugin=gutenberg&theme=blue-note&url=/wp-admin/post-new.php

Even better, let’s link someone to the theme’s templates in the Site Editor:

https://playground.wordpress.net/?plugin=gutenberg&theme=blue-note&url=/wp-admin/site-editor.php?path=%2Fwp_template

Again, there are plenty more parameters than what we have explored in this article that are worth checking out in the WordPress Playground documentation.

Sharing With An Embedded iFrame

We already know this is possible because the best example of it is the WordPress Playground developer page. There’s a Playground instance running and embedded directly on the page. Even when you spin up a new Playground instance, you’re effectively running an iframe within an iframe.

Let’s say we want to embed a WordPress site configured with the Pendant theme and the Gutenberg plugin:

<iframe width="800" height="650" src="https://playground.wordpress.net/?plugin=gutenberg&theme=pendant&mode=seamless" allowfullscreen></iframe>

So, really, what we’re doing is using the source URL in a different context. We can share the URL with someone, and they get to access the configured site in a browser. In this case, however, we are dropping the URL into an iframe element in HTML, and the Playground instance renders on the page.

Not to get too meta, but it’s pretty neat that we can log into a WordPress production site, create a new page, and embed a Playground instance on the page with the Custom HTML Block:

What I like about sharing Playground sites this way is that the instance is effectively preserved and always accessible. Sure, the data will not persist on a page refresh, but create the URL once, and you always have a copy of it previewed on another page that you host.

Speaking of which, WordPress Playground can be self-hosted. You have to imagine that the current Playground API hosted at playground.wordpress.net will get overburdened with time, assuming that Playground catches on with the community. If their server is overworked, I expect that the hosted API will either go away (breaking existing instances) or at least be locked for creating new instances.

That’s why self-hosting WordPress Playground might be a good idea in the long run. I can see WordPress developers and agencies reaching for this to provide customers and clients with demo work. There’s so much potential and nuance to self-hosting Playground that it might even be worth its own article.

The documentation provides a list of parameters that can used in the Playground URL.

Sharing With JSON Blueprints

This “modern” era of WordPress is all about block-based layouts that lean more heavily into JaveScript, where PHP has typically been the top boss. And with this transition, we gained the ability to create entire WordPress themes without ever opening a template file, thanks to the introduction of theme.json.

Playground can also be configured with structured data. In fact, you can see the Playground website’s JSON configurations via this link. It’s pretty incredible that we can both configure a Playground site without writing code and share the file with others to sync environments.

Here is an example pulled directly from the Playground docs:

{
  "$schema": "https://playground.wordpress.net/blueprint-schema.json",
  "landingPage": "/wp-admin/",
  "preferredVersions": {
    "php": "8.0",
    "wp": "latest"
   },
  "steps": [{
    "step": "login",
    "username": "admin",
    "password": "password"
  }]
}

We totally can send this file to someone to clone a site we’re working on. Or, we can use the file in a self-hosted context, and others can pull it into their own blueprint.

Interestingly, we can even ditch the blueprint file altogether and write the structured data as URL fragments instead:

https://playground.wordpress.net/#{"preferredVersions": {"php":"7.4", "wp":"5.9"}}

That might get untenable really fast, but it is nice that the WordPress Playground team is thinking about all of the possible ways we might want to port WordPress.

Advanced Playground Configurations

Up to now, we’ve looked at a variety of ways to configure WordPress Playground using APIs that are provided by or based on playground.wordpress.net. It’s fast, convenient, and pretty darn flexible for something so new and experimental.

But let’s say you need full control to configure a Playground instance. I mean everything, from which themes and plugins are preinstalled to prepublished pages and posts, defining php.ini memory limits, you name it. The JavaScript API is what you’ll need because it is capable of executing PHP code, make requests, manage files and directories, and configuring parts of WordPress that none of the other approaches offer.

The JavaScript API is integrated into an iframe and uses the @wp-playground/client npm package. The Playground docs provide the following example in its “Quick Start” guide.

<iframe id="wp" style="width: 100%; height: 300px; border: 1px solid #000;"></iframe>

<script type="module">
  // Use unpkg for convenience
  import { startPlaygroundWeb } from 'https://unpkg.com/@wp-playground/client/index.js';

  const client = await startPlaygroundWeb({
    iframe: document.getElementById('wp'),
    remoteUrl: https://playground.wordpress.net/remote.html,
  });
  // Let's wait until Playground is fully loaded
  await client.isReady();
</script>

This is an overly simplistic example that demonstrates how the JavaScript API is embedded in a page in an iframe. The Playground docs provide a better example of how PHP is used within JavaScript to do things, like execute a file pointed at a specific path:

php.writeFile(
  "/www/index.php",
  `<?php echo "Hello world!";"`
);
const result = await php.run({
  scriptPath: "/www/index.php"
});
// result.text === "Hello world!"

Adam Zieliński and Thomas Nattestad offer a nicely commented example with multiple tasks in the article they published over at web.dev:

import {
  connectPlayground,
  login,
  connectPlayground,
} from '@wp-playground/client';

const client = await connectPlayground(
  document.getElementById('wp'), // An iframe
  { loadRemote: 'https://playground.wordpress.net/remote.html' },
);
await client.isReady();

// Login the user as admin and go to the post editor:
await login(client, 'admin', 'password');
await client.goTo('/wp-admin/post-new.php');

// Run arbitrary PHP code:
await client.run({ code: '<?php echo "Hi!"; ?>' });

// Install a plugin:
const plugin = await fetchZipFile();
await installPlugin(client, plugin);

Once again, the scope and breadth of using the JavaScript API for advanced configurations is yet another topic that might warrant its own article.

Wrapping Up

WordPress Playground is an excellent new platform that’s an ideal testing environment for WordPress themes, plugins… or even WordPress itself. Despite the fact that it is still in its early days, Playground is already capable of some pretty incredible stuff that makes WordPress more portable than ever.

We looked at lots of ways that Playground accomplishes this. Just want to check out a new theme? Use the playground.wordpress.net URL configured with parameters supported by the Query API, or grab the Chrome extension. Need to do a quick test of your theme in a different PHP environment? Use the wp-now package to spin up a test site locally. Want to let others demo a plugin you made? Embed Playground in an iframe on your site.

WordPress Playground is an evolving space, so keep your eye on it. You can participate in the discussion and request a feature through a pull request or report an issue that you encounter in your testing. In the meantime, you may want to be aware of what the WordPress Playground team has identified as known limitations of the service:

No access to plugins and theme directories in the browser.
The theme and plugin directories are not accessible due to the fact that Playgrounds are not connected to the internet, but are virtual environments.
Instances are destroyed on a browser refresh.
Because WordPress Playground uses a browser-based temporary database, all changes and uploads are lost after a browser refresh. If you want to preserve your changes, though, use the export feature to download a zipped archive of the instance. Meanwhile, this is something the team is working on.
iFrame issues with anchor links.
Clicking a link in a Playground instance that is embedded on a page in an iframe may trigger the main page to refresh, causing the instance to reset.
iFrame rendering issues.
There are reports where setting the iframe’s src attribute to a blobbed URL instead of an HTTP URL breaks links to assets, including CSS and images.

How will you use WordPress Playground? WordPress Playground creator Adam Zieliński recently shipped a service that uses Playground to preview pull requests in GitHub. We all know that WordPress has never put a strong emphasis on developer experience (DX) the same way other technical stacks do, like static site generators and headless configurations. But this is exactly the sort of way that I imagine Playground improving DX to make developing for WordPress easier and, yes, fun.

References & Resources

“InstaWP Review: Create WordPress Sandbox Sites the Easy Way,” Colin Newcomer (WP Mayor)
“TasteWP Review: Free WordPress Hosting to Test Plugins & Themes,” Xaif (WebVerge)
WordPress Playground Resources (WordPress Developer Resources)
WordPress Playground for VS Code (Visual Studio Marketplace)
“Exploring the Future of Web Development with WebAssembly and PHP,” Angel M De Miguel (WordPress Developer Blog)
“Build In-browser WordPress Experiences with WordPress Playground and WebAssembly,” Adam Zieliński and Thomas Nattestad (web.dev)
“WordPress Playground Lets You Run WordPress Entirely in Your Browser,” Romain Dillet (TechCrunch)
“An Introduction to WordPress Playground,” Tom Rankin (WPShout)
“Preview WordPress Core Pull Requests with Playground,” Sarah Gooding (WP Tavern)

September 28, 2023

Exploring Enhanced Patterns In WordPress 6.3

Reusable blocks, introduced in WordPress 5.0, allow users to create and save custom blocks that can be used across different pages or posts. This increases efficiency and consistency by allowing users to create personalized blocks of content that can be easily reused. Subsequently, in WordPress 5.5, block patterns were introduced, allowing users to design layout patterns comprised of multiple blocks.

While reusable blocks have allowed users to create their own content blocks that can be reused across the site while maintaining their consistency, block patterns have offered a convenient to quickly apply common design patterns to pages and posts.

Reusable blocks and block patterns may seem similar at first glance, but there is one crucial distinction between them. Reusable blocks can be easily created directly in the Post Editor, allowing users to generate and reuse their own custom content blocks. In contrast, block patterns are established patterns installed or registered in block themes that cannot be created directly in the WordPress admin.

Starting with WordPress 6.3, reusable blocks and block patterns have been combined to form a feature called “Patterns” that provides users with the flexibility to choose whether they want to synchronize all instances of a pattern — similar to reusable blocks — or apply patterns without syncing content. The new functionality, available now in the Post Editor, empowers users to craft patterns that can function as both reusable blocks and patterns, catering to their specific requirements.

Selecting the “Create Reusable block” option triggers a popup that prompts you to name the reusable block.

Once named, the reusable block is saved and can be accessed in the Block Inserter. It’s a little tough to spot because it is the only section of the Block Inserter that is labeled with an icon instead of a text label.

Perhaps a more convenient way to access the block is to type a forward slash (/) in the Post Editor, followed by the reusable block’s name.

Making changes to a reusable block isn’t difficult, but finding where to make changes is. You must click on the Post Editor settings while editing a page or post, then select the “Manage Reusable blocks” option.

This will take you to another new editing screen where you can directly edit reusable blocks as you like. I sometimes bookmark this screen as a shortcut. Once saved, changes to reusable blocks are applied throughout the site.

Creating Block Patterns in WordPress 6.2

Unlike reusable blocks, site creators are unable to create block patterns from the Post Editor. Instead, they are treated more like plugins, where block patterns are installed and activated before they are available in the Post Editor. Once they are available, they can be accessed with the Block Inserter or a forward slash command the same way reusable blocks are added to pages and posts.

The neat thing about this plugin-like treatment is that there is a Patterns Directory full of patterns created and submitted by the WordPress community, just like we have the Plugins Directory. But that also means that patterns are developed and need to be included in a theme.

Registering Custom Block Patterns With PHP

The register-block-pattern API function was first introduced in WordPress 6.0, allowing theme authors to register custom block patterns:

register_block_pattern(
  'my-first-pattern/hello-world',
  array(
    'title' => __( 'Hello World', 'my-first-pattern' ),
    'description' => _x( 'A simple paragraph block.', 'my-first-pattern' ),
    'content' => "<!-- wp:paragraph -->Hello world<!-- /wp:paragraph -->",
  )
);

The content argument may contain any raw HTML markup, which means it’s possible to configure a group of blocks that you want to make into a pattern directly in the Post Editor, then copy and paste that group into the content field. Pasting blocks as plain text reveals the underlying raw HTML.

We want to make that into a custom function and add an action that fires the function when the theme is initialized.

function mytheme_register_block_patterns() {
  register_block_pattern( ... );
}
add_action( 'init', 'mytheme_register_block_patterns' );

Just as a block pattern can be registered, it can be unregistered programmatically using the unregister-block-pattern function. All it takes is the title argument.

function mytheme_unregister_my_patterns() {
  unregister_block_pattern(
    'my-first-pattern/hello-world',
    array(
      'title' => __( 'Hello World', 'my-first-pattern' ),
    )
  );
}
add_action( 'init', 'my_first_patterns' );

Registering Custom Block Patterns Via The `/patterns` Directory

Not to be confused with the Patterns Directory I shared earlier, where you can find and install patterns made by community contributors, WordPress 6.0 has also supported registering block patterns in a /patterns file directory that lives in the theme folder.

The process to register a block pattern from here is similar to the PHP approach. In fact, each pattern is contained in its own PHP file that contains the same raw HTML that can be copied and pasted into the register-block-pattern function’s content argument… only the function is not required.

Here is an example showing a pattern called “Footer with text” that is saved as footer.php in the /patterns folder:

<?php
/**
 * Title: Footer with text.
 * Slug: theme-slug/footer
 * Categories: site-footer
 * Block Types: core/template-parts/footer
 * Viewport Width: 1280
 */
?>
<!-- block markup here -->

This particular example demonstrates another feature of block patterns: contextual block types. Declaring the “Block Types” property as core/template-parts/footer attaches the pattern to a template part (located in a /template-parts folder that sits alongside the /patterns folder) called footer.php. The benefit of attaching a block pattern to a block type is that it registers the pattern as an available transform of that block type, which is a fancy way of saying that the pattern is applied on top of another block. That way, there’s no need to modify the structure of the existing template part to apply the pattern, which is sort of similar to how we typically think of child theming but with patterns instead.

Want to add your custom block pattern to a theme template? That’s possible with the wp:pattern context:

<!-- wp:pattern { "slug":"prefix/pattern-slug" } /-->

Any entire template can be created with nothing but block patterns if you’d like. The following is an example taken from the Automattic’s Archeo theme. The theme’s home.html template file clearly demonstrates how a template can be constructed from previously registered patterns, pattern files in the /patterns theme folder, and the wp:pattern context:

<!-- wp:template-part { "slug":"header","tagName":"header" } /-->

<!-- wp:group { "layout":{ "inherit":"true" } } -->
  <div class="wp-block-group">
    <!-- wp:pattern { "slug":"archeo/image-with-headline-description" } /-->
    <!-- wp:pattern { "slug":"archeo/simple-list-of-posts-with-background" } /-->
    <!-- wp:pattern { "slug":"archeo/layered-images-with-headline" } /-->
  </div>
<!-- /wp:group -->

<!-- wp:template-part { "area":"footer","slug":"footer","tagName":"footer" } /-->

The theme’s footer.php pattern is added to the /parts/footer.html template file before it is used in the home.html template, like this:

<!-- wp:pattern { "slug":"archeo/footer" } /-->

Additional information about registering block patterns is available in the WordPress Theme Handbook. You can also discover many use cases for block patterns in the explainer of Automattic’s themes repository on GitHub.

Reusable Blocks And Patterns In WordPress 6.3

WordPress 6.3 is notable for many reasons, one being that the reusable blocks and block patterns features are combined into a single feature simply called Patterns. The idea is that reusable blocks and block patterns are similar enough in nature that we can decide whether or not a pattern is reusable at the editing level. Instead of determining up-front whether or not you need a reusable block or a block pattern, create a Pattern and then determine whether to sync the Pattern’s content across the site.

The result is a single powerful feature that gives us the best of both worlds. WordPress 6.3 not only combined the reusable blocks and block patterns but made UI changes to the WordPress admin as well. Let’s zero in on those changes and how Patterns work in the new system.

Creating Synced Patterns

Not only are Patterns offered in the Site Editor, but they can be inserted into a page or post with the Post Editor. In fact, it works just like reusable blocks did before combining with block patterns. The only difference is that the “Create Reusable block” option in the contextual menu is now called “Create pattern/reusable block” instead.

The process for creating a pattern is mostly the same, too. Select any block or group of blocks that have been inserted into the page, open the contextual menu, and select “Create pattern/reusable block.” I hope that label becomes simply “Create Pattern” in a future release. This longer label is probably there to help with the transition.

This is where things start to diverge from WordPress 6.2. Clicking “Create pattern/reusable block” still triggers a popup asking you to name the Pattern, but what’s new is a toggle to enable synced content support.

Once the pattern is saved, it is immediately available in the Block Inserter or with a slash (/) command.

Creating Standard, Unsynced Patterns

This feature, which has been a long time coming, allows us to create our own custom patterns, akin to the flexibility of reusable blocks in the Site Editor.

Let’s demonstrate how standard, unsynced Patterns work but do it a little differently than the synced example. This time, we’ll start by copying this two-column text pattern from the Patterns Directory and pasting it into a page. I’m going to change the colors around a bit and make a few other minor tweaks to the copied pattern just for fun. I’m also naming it “Two-columns Text Unsynced Pattern” in the popup. The only difference between this Pattern and the synced Pattern we created earlier is that I’m disabling the Synced setting.

That’s really it! I just created a new custom pattern based on another pattern pulled from the Patterns Library and can use it anywhere on my site without syncing the content in it. No PHP or special file directories are needed!

Patterns Are Accessible From The Site Editor

You are probably very familiar with the Site Editor. As long as your WordPress site is configured as a block theme, navigating to Appearance → Site Editor opens up the site editing interface.

WordPress 6.3 introduces a newly redesigned sidebar panel that includes options to edit navigation, styles, pages, templates, and… patterns. This is a big deal! Patterns are now treated like modular components that can be used to craft templates at the Site Editor level. In other words, block patterns are no longer relegated solely to the Post Editor.

Clicking into Patterns in the Site Editor displays all of your saved Patterns. The patterns are conveniently split up between synced and unsynced patterns, and clicking on any of them opens up an editing interface where changes can be made and saved.

Another interesting Site Editor update in WordPress 6.3 is that patterns and template parts are now together. Previous versions of WordPress put Template Parts in the Site Editor’s top-level navigation. WordPress 6.3 replaces “Template Parts” in the Site Editor navigation with “Patterns” and displays “Template Parts” alongside patterns in the resulting screen.

I’ll reserve judgment for later, but it’s possible that this arrangement opens up some confusion over the differences between patterns and template parts. That’s what happened when patterns and reusable blocks were separate but equal features with overlapping functionality that needed to be combined. I wonder if template parts will get wrapped up in the same bundle down the road now that there’s less distinction between them and patterns in the Site Editor.

Another thing to notice about the patterns interface in the Site Editor is how patterns are organized in folders in the side panel. The folders are automatically created when a pattern is registered as a contextual block pattern, as we demonstrated earlier when revisiting how block patterns worked in previous versions of WordPress. A lock icon is displayed next to a folder when the patterns are bundled with the active theme, indicating that they are core to the theme’s appearance rather than a pattern that was created independently of the theme. Locked patterns are ones you want to build off of, the same way we registered a Pattern earlier as a contextual block type.

Finally, a new pattern (or template part, for that matter) can be created directly from the Site Editor without having to leave and create it in the Post Editor. This is an extremely nice touch that prevents us from having to jump between two UIs as we’ve had to do in previous versions of WordPress.

Remember that screen I showed earlier that displays when clicking “Manage Reusable blocks” in the Post Editor? Well, now it is called “Patterns,” and it, too, is a direct link in the Site Editor.

This screen displays all custom saved patterns but does not show patterns that are bundled with the theme. This may change in future releases. Matias Ventura, Gutenberg project architect, says in this GitHub discussion thread that patterns will eventually be served through the Pattern Directory instead of being bundled resources. Maybe then we’ll see all available patterns instead of only custom patterns.

Using Patterns As Starter Templates

A common use case of the earlier Patterns API that was introduced in WordPress 6.0 has been to display a few sets of starter content patterns as options that users may choose when creating a new page template in the Site Editor. The idea is to provide you with a template with a predefined layout rather than starting with a blank template and to show a preview of the template’s configuration.

The updated Patterns API in WordPress 6.2 allows us to do this more easily by creating custom patterns for specific template types. For example, we could create a set of patterns associated with the template for single posts. Or another set of patterns for the 404 template. The benefit of this, of course, is that we are able to use patterns as starter templates!

Let’s walk through the process of using patterns as starter page templates, beginning first by registering our custom patterns with our friend, register-block-pattern(). We do have the option to register patterns in the theme’s /patterns folder, as we did earlier, but I found it did not work. Let’s go with the function instead for the tour.

Registering Custom Patterns With `register-block-pattern()`

We’ll start with a function that registers a Pattern that we are going to associate with the theme’s 404 page template. Notice the templateTypes argument that allows us to link the pattern to the template:

function mytheme_register_block_patterns() {
  register_block_pattern(
    'wp-my-theme/404-template-pattern',
     array(
       'title' => __( '404 Only template pattern', 'wp-my-theme' ),
       'templateTypes' => array( '404' ),
       'content' => '<!-- wp:paragraph { "align":"center","fontSize":"x-large" } --><p class="has-text-align-center has-x-large-font-size">404 pattern</p><!-- /wp:paragraph -->',
    )
  );
}
add_action( 'init', 'mytheme_register_block_patterns' );

I pulled the bulk of this function from a GitHub Gist. It’s a small example, but you can see how cluttered things could get if we are registering many patterns for a single template. Plus, the more patterns registered for a template, the bigger that page gets, making the template as a whole difficult to read, preview, and maintain.

The default Twenty Twenty-Two WordPress theme comes with 66 patterns. That could get messy in the theme folder, but the theme smartly has added an /inc folder containing individual PHP files for each registered pattern. The same sort of strategy the themes have used to break up functions registered in the functions.php to prevent it from getting too convoluted.

For the sake of example, let’s register a few starter patterns the same way. First, we’ll add a new /inc folder to the top level of the theme folder, followed by another folder contained in it called /patterns. And in that folder, let’s add a new file called block-patterns.php. In that file, let’s add a modified version of the Twenty Twenty-Two theme’s block registration function mapped to four patterns we want to register for the 404 page template:

404-blue.php
page-not-found.php

Here’s how it all looks:

Let’s turn our attention to the patterns themselves. Specifically, let’s open up the 404-blue.php file and add the code from this Pattern in the Patterns Directory and this one as well:

<?php
/**
  * Blue pattern
  * source: https://wordpress.org/patterns/pattern/seo-friendly-404-page/
**/
?>

return array(
  'title' => __( '404 Blue', 'mytheme' ),
  'categories' => array( 'post' ),
  'templateTypes' => array( '404' ),
  'inserter' => 'yes',
  'content' => '<!-- wp:columns { "align":"full" } -->
<div class="wp-block-columns alignfull"><!-- wp:column { "width":"100%" } -->
<div class="wp-block-column" style="flex-basis:100%"><!-- wp:columns { "style":{" color":{ "gradient":"linear-gradient(308deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100% )" },"spacing":{ "padding":{ "right":"20px","bottom":"100px","left":"20px","top":"100px"} } } } -->
<div class="wp-block-columns has-background" style="background:linear-gradient(308deg,rgba(6,147,227,1) 0%,rgb(155,81,224) 100%);padding-top:100px;padding-right:20px;padding-bottom:100px;padding-left:20px"><!-- wp:column { "width":"1920px" } -->
<div class="wp-block-column" style="flex-basis:1920px"><!-- wp:heading { "textAlign":"center","level":1,"style":{ "typography":{ "textTransform":"uppercase","fontSize":"120px" } },"textColor":"white" } -->
<h1 class="has-text-align-center has-white-color has-text-color" style="font-size:120px;text-transform:uppercase"><strong>404</strong></h1>
<!-- /wp:heading -->

<!-- wp:heading { "textAlign":"center","style":{ "typography":{ "textTransform":"uppercase" } },"textColor":"white" } -->
<h2 class="has-text-align-center has-white-color has-text-color" style="text-transform:uppercase">😭 <strong>Page Not Found</strong> 💔</h2>
<!-- /wp:heading -->

<!-- wp:paragraph { "align":"center","textColor":"white" } -->
<p class="has-text-align-center has-white-color has-text-color">The page you are looking for might have been removed had it's name changed or is temporary unavailable. </p>
<!-- /wp:paragraph -->

<!-- wp:search { "label":"","showLabel":false,"placeholder":"Try Searching for something else...","width":100,"widthUnit":"%","buttonText":"Search","buttonPosition":"no-button","align":"center","style":{ "border":{ "radius":"50px","width":"0px","style":"none" } },"backgroundColor":"black","textColor":"white" } /-->

<!-- wp:paragraph { "align":"center","textColor":"white" } -->
<p class="has-text-align-center has-white-color has-text-color">💡 Or you can return to our <a href="#">home page</a> or <a href="#">contact us</a> if you can't find what you are looking for</p>
<!-- /wp:paragraph -->

<!-- wp:buttons { "layout":{"type":"flex","justifyContent":"center" } } -->
<div class="wp-block-buttons"><!-- wp:button { "backgroundColor":"black","textColor":"white","style":{ "border":{ "radius":"50px" },"spacing":{ "padding":{ "top":"15px","right":"30px","bottom":"15px","left":"30px" } } } } -->
<div class="wp-block-button"><a class="wp-block-button__link has-white-color has-black-background-color has-text-color has-background" style="border-radius:50px;padding-top:15px;padding-right:30px;padding-bottom:15px;padding-left:30px">Go to Homepage</a></div>
<!-- /wp:button -->

<!-- wp:button { "backgroundColor":"black","textColor":"white","style":{ "border":{ "radius":"50px" },"spacing": { "padding":{ "top":"15px","bottom":"15px","left":"60px","right":"60px" } } } } -->
<div class="wp-block-button"><a class="wp-block-button__link has-white-color has-black-background-color has-text-color has-background" style="border-radius:50px;padding-top:15px;padding-right:60px;padding-bottom:15px;padding-left:60px">Contact Us</a></div>
<!-- /wp:button --></div>
<!-- /wp:buttons -->

<!-- wp:paragraph { "align":"center","textColor":"white","fontSize":"small" } -->
<p class="has-text-align-center has-white-color has-text-color has-small-font-size">Find the page at our <a href="#sitemap">sitemap</a></p>
<!-- /wp:paragraph --></div>
<!-- /wp:column --></div>
<!-- /wp:columns --></div>
<!-- /wp:column --></div>
<!-- /wp:columns -->'

Once again, I think it’s worth calling out the templatesTypes argument, as we’re using it to link this “404 Blue” pattern to the 404 page template. This way, the pattern is only registered to that template and that template alone.

Now that we’ve finished adding the right folders and files and have registered the “404 Blue” pattern to the 404 page template, we can create the 404 page template and see our patterns at work:

Open up the WordPress admin and navigate to the Site Editor (Appearance → Editor).
Open the Templates screen by clicking “Templates” in the Site Editor side panel.
Click “Add New Template”.
Select the “Page: 404” option.

Selecting the 404 page template triggers a popup modal that prompts you to choose a pattern for the page using — you guessed it — the patterns we just registered! The default starter pattern established by the theme is displayed as well.

Custom Template With Starter Patterns

What we just did was create a set of patterns linked to the theme’s 404 page template. But what if we want to link a pattern set to a custom page template? When the Site Editor was first introduced, it only supported a few core page templates, like page, post, and front page. Now, however, we not only have more options but the choice to create a custom page template as well.

So, let’s look at that process by adding new files to the /inc/patterns folder we created in the last example:

about-me.php,
my-portfolio.php.

We won’t grab code examples for these since we spelled out the full process in the last example. But I will point out that the main difference is that we change the templateTypes argument in each pattern file so that it links the patterns to the custom templates we plan on creating in the Site Editor:

<?php
/**
  * About Me
  * source: https://wordpress.org/patterns/pattern/seo-friendly-404-page/
**/
?>

return array(
  'title' => __( 'About Me', 'mytheme' ),
  'categories' => array( 'post' ),
  'templateTypes' => array( 'portfolio', 'author' ),
  // etc.
);

Now we can go back to the Site Editor, open the Templates screen, and select “Add new template” as we did before. But this time, instead of choosing one of the predefined template options, we will click the “Custom template” option at the bottom. From there, we get a new prompt to name the custom template. We’ll call this one “My Portfolio”:

Next, we could try to choose patterns for the template, but it leads to a blank page at the time of this writing. Instead, we can skip that step, open the template in the editor, and add the patterns to the template there as you would any other block or pattern. Click the + button in the top-left corner of the editor to open the block inserter side panel, then open the “Patterns” tab and select patterns to preview them in the custom template.

As a side note, do you see how the patterns are bundled in categories (e.g., Featured, Posts, Text, and so on)? That’s what the categories argument in the pattern file’s return array sets. If a pattern is not assigned a category, then it will automatically go into an “Unclassified” category.

The WordPress Developer Blog provides additional examples of custom starter templates.

Using Patterns In The Post Editor

We can insert custom patterns into pages and posts using the Post Editor in the same way we can insert them into templates using the Site Editor. In the Post Editor, any custom patterns that are registered but not linked to specific templates are listed in the “My patterns” category of the Block Inserter’s “Patterns” tab.

This discussion on GitHub suggests that displaying categories for custom patterns will be prioritized for a future release.

Using Patterns From The Patterns Directory

We’ve certainly danced around this topic throughout the rest of the examples we’ve covered. We’ve been copying and pasting items from the Patterns Directory to register our own custom patterns and link them to specific page templates. But let’s also see what it’s like to use a pattern directly from the Patterns Directory without modifying anything.

If you’ve installed a plugin from the Plugins Directory, then you are already familiar with installing patterns from the Patterns Directory. It’s the same concept: members from the community contribute open-source patterns, and anyone running a WordPress site can use them.

The library allows users to select patterns that are contributed by the “community” or “curated” by the WordPress.org team, all of which fall in a wide range of different categories, from Text and Gallery to Banners and Call to Action, among many others.

Adding a pattern to a site isn’t exactly the same as installing a plugin. A plugin can be installed directly from the Plugins Directory via the WordPress admin and activated from there. Patterns, however, should be added to a block theme’s theme.json, registered in the patterns object using the pattern’s slug as the value. Multiple patterns can be registered with comma-separation:

{
  "version": 2,
  "patterns": [ "short-text", "patterns-slug" ],
  // etc.
}

The following example uses a pattern called “Slanted Style Call To Action” from the Patterns Directory. It is used in the theme.json file of a theme I cloned from the default Twenty Twenty-Three theme:

{
  "version": 2,
  "patterns": [ "slanted-pattern", "slanted-style-call-to-action" ]
}

Now, we can view the newly added pattern in the Post Editor by opening the Block Inserter and selecting the Patterns tab, where the pattern is listed. Similarly, it’s possible to use the Block Inserter’s search function to pull up the pattern:

For those of you who would like to use patterns directly from the Pattern Directory without first registering them, the GutenbergHub team has created a page builder app that makes that possible. They have an introductory video that demonstrates it.

You can copy the code from the app and paste it into a site, which makes it much easier to build complex layout patterns in a low-code fashion. Jamie Marsland shows in this short video (at 1:27) how the app can be used to create an entire page layout, similar to a full-fledged page builder, by selecting desired page sections from the Patterns Directory.

Learn more about creating starter patterns in the “Utilizing patterns” section of the WordPress Developer Resources documentation.

Aspect Ratio For Large Images

You may have already noticed that the core/image block didn’t allow dimensions or aspect-ratio controls for images that were added to the block. With WP 6.3, you can control the aspect ratio of an image, which will be preserved when you change it with another one of different sizes.

This feature will be helpful when replacing images in block patterns. This short video shows you how image aspect ratio can be used in block patterns.

For an additional in-depth discussion and rationale, please visit GitHub PRs #51078, #51144, #50028, and #48079.

Wrapping Up

In this article, we discussed the new evolving block patterns feature in WordPress 6.3 and showed a few use cases for creating custom patterns within the site editor. This new feature provides users with unlimited ways to arrange blocks and save them as patterns for widespread use. The integration of reusable blocks and traditional patterns within the Site and Post Editors aims to streamline workflows, enhance content creation, and prepare for upcoming enhancements in WordPress 6.4.

In addition, the WordPress 6.4 roadmap includes more advanced features for patterns that we have to look forward to:

Set categories;
Update the inserter experience to ensure consistency between synced and unsynced;
Improve compatibility for non-block themes;
Iterate on the patterns page’s empty category state;
Synced patterns not receiving the alignment attribute in the editor.

You can check out this WordPress TV video to learn more details about how the block patterns are evolving. Additionally, work-in-progress issues can be tracked on GitHub.

Note: Since this article was written, WordPress 6.4 Beta 1 has been released. The new release allows users to better organize synced and unsynced patterns with categories as part of the creation process. Please refer to the release note for more up-to-date information.

Difference Between High-Level and Low-Level Programming Languages

High-level and low-level programming languages are two distinct categories of programming languages used for writing computer programs. They differ significantly in terms of their level of abstraction, ease of use, and the types of tasks they are best suited for. In this extensive discussion, we'll explore the differences between these two language categories in detail.

High-Level Programming Languages

1. Abstraction Level

High-level programming languages are designed with a high level of abstraction. This means that they provide programmers with a set of easy-to-understand and human-readable commands and structures.
These languages abstract away many of the low-level details of the computer's hardware, making it easier for developers to focus on solving problems rather than managing hardware-specific intricacies.

2. Readability and Ease of Use

High-level languages are known for their readability and ease of use. Programmers can write code that closely resembles human language, which makes it more accessible to a wider range of developers.
This readability often leads to shorter development times, as code can be written and maintained more efficiently.

3. Portability

High-level languages are typically portable, meaning that code written in one high-level language can often be run on different computer architectures or operating systems with minimal modification.
This portability is facilitated by the use of interpreters or compilers that translate high-level code into machine code or an intermediate representation.

4. Productivity

High-level languages are designed to enhance programmer productivity. They provide built-in functions and libraries that simplify common tasks.
Programmers can focus on problem-solving and application logic rather than getting bogged down in low-level details.

5. Examples

Examples of high-level programming languages include Python, Java, C++, JavaScript, Ruby, and PHP.
Python, for instance, is known for its simplicity and readability, making it a popular choice for beginners and experienced developers alike.

6. Performance

High-level languages generally sacrifice some level of performance for ease of use and portability. They rely on interpreters or compilers to convert code into machine code, which can introduce some overhead.
While high-level languages can be optimized for performance in many cases, they may not be as efficient as low-level languages for certain types of tasks, such as system-level programming.

Low-Level Programming Languages

1. Abstraction Level

Low-level programming languages are closer to the hardware and have a lower level of abstraction. They provide more direct control over the computer's hardware resources.
Programmers working with low-level languages have to manage memory, registers, and hardware-specific details explicitly.

2. Readability and Ease of Use

Low-level languages are known for their reduced readability and increased complexity. They often involve working with cryptic symbols and require a deep understanding of computer architecture.
Writing code in low-level languages can be error-prone and time-consuming, as programmers must handle many low-level details.

3. Portability

Low-level languages are generally not portable. Code written in a low-level language is often specific to a particular computer architecture or operating system.
To run on different platforms, code must be rewritten or adapted for each target system.

4. Productivity

Low-level languages can be less productive for most application development tasks because they require more effort and time to write and debug.
They are typically reserved for specialized tasks where fine-grained control over hardware is necessary.

5. Examples

Examples of low-level programming languages include Assembly language and C.
Assembly language provides a symbolic representation of machine code instructions, while C offers a higher level of abstraction compared to Assembly but still allows for close control over hardware.

6. Performance

Low-level languages can deliver superior performance in situations where fine-tuned control over hardware is critical. For tasks like operating system development, device drivers, and embedded systems, low-level languages are often preferred.
They allow for efficient use of system resources and direct manipulation of memory and hardware registers.

Use Cases and Trade-Offs

High-Level Languages

High-level languages are ideal for a wide range of application development tasks, including web development, data analysis, scientific computing, and more.
They are the preferred choice for rapid development, prototyping, and projects where performance is not the primary concern.
High-level languages abstract away complexity, making them suitable for programmers with varying levels of expertise.

Low-Level Languages

Low-level languages are essential for system-level programming tasks, such as developing operating systems, device drivers, and firmware for embedded systems.
They are used in situations where absolute control over hardware and maximum performance are required.
Programmers working with low-level languages typically have a deep understanding of computer architecture and hardware.

Translating Between High-Level and Low-Level Languages

In practice, it is common to use both high-level and low-level languages within a single project or software ecosystem. This is often achieved through the use of libraries and interfaces.
High-level languages may include mechanisms for calling functions or using libraries written in low-level languages.
Conversely, low-level languages may provide ways to interface with high-level languages or use their libraries.
This mix allows developers to leverage the strengths of each type of language while managing the trade-offs.

Choosing Between High-Level and Low-Level Languages

The choice between high-level and low-level languages depends on the specific requirements of a project:

September 5, 2023

Where Is php.ini in WordPress? (& How to Edit This File)

Are you wondering where the php.ini file is located on your website?

Php.ini is a critical file in your WordPress installation. You’ll often need to edit it for better functionality and performance of your website. However, many website owners don’t know where it is located.

In this article, we’ll show you where is php.ini in WordPress and how to edit this file.

Where is php.ini in WordPress and how to edit it

To help you navigate the post, you can click the links below to jump to any section you’re interested in.

What is php.ini file in WordPress?
Why Do You Need to Edit php.ini File in WordPress?
Finding the php.ini File Location in WordPress
Use cPanel to Locate the php.ini File
Locate the php.ini File using a File Manager Plugin
Finding php.ini Path in WordPress using the phpinfo.php File
Editing the php.ini File in WordPress

What is php.ini file in WordPress?

The php.ini file is a default configuration file for PHP on your WordPress site. PHP is a scripting and programming language on which WordPress is written.

It’s used on the server side of things, which means it runs on your web hosting server. Through PHP, WordPress is able to display your blog posts, products, media content, and more.

The php.ini file configures how PHP works and can have a huge impact on your website’s functionality. Whenever PHP runs on your site, it will look for this file.

That said, let’s see why and when you’ll need to edit the file on your website.

Why Do You Need to Edit php.ini File in WordPress?

The php.ini file is very important for your site’s performance and functionality. This means you can edit it to ensure your website works smoothly or resolve any errors.

For instance, editing the php.ini file allows you to increase the maximum file upload size and resource limits.

If you have a photography website or a site that requires a lot of videos and images, then you might encounter an error ‘uploaded file exceeds the upload_max_filesize’ message.

Increasing the upload size in the php.ini file will help resolve this error and allow you to easily upload larger media files. Plus, you can also increase the available memory to accommodate long blog posts with lots of images.

Similarly, the php.ini file lets you edit the file timeout settings. If a file takes longer to process, then your site can timeout and stop processing the request. To prevent this from happening, you can increase the number of seconds before timeout through the php.ini file.

Lastly, you’ll also be able to enable or disable file extensions in PHP by editing the file. This is really useful if you see a ‘Your PHP installation appears to be missing the MySQL extension’ error on your site. It helps fix this error and resolve issues when establishing a database connection.

Now, let’s look at where the php.ini file is located in WordPress.

Finding the php.ini File Location in WordPress

There are several ways you can locate and view the php.ini file.

You can use your hosting service’s cPanel, a plugin, or an FTP client to access your website files and folders.

1. Use cPanel to Locate the php.ini File

You can use the cPanel provided by your WordPress hosting provider and access the File Manager to locate the file. This method is pretty straightforward, and you don’t need to edit any code.

For this tutorial, we will use Bluehost to access the cPanel. If you’re using another hosting service, then the steps may vary.

First, you’ll need to log in to your Bluehost account. From here, simply click the ‘Advanced’ option in the left panel.

On the next screen, you’ll see the cPanel of your website.

Simply scroll down to the Files section and click the File Manager option.

After that, you’ll see all the folders and files of your WordPress website.

From the left panel, you can navigate to the ‘public_html’ folder. Next, you should see files in the folder on your right. You can scroll down and locate the ‘php.ini’ file.

To download the file for editing, you can simply right-click the php.ini file and save it on your computer.

2. Locate the php.ini File using a File Manager Plugin

Another way of finding out where is the php.ini file in WordPress is by using a plugin like WP File Manager.

It is a free WordPress plugin that lets you edit, download, delete, and organize your files and folders directly from the WordPress dashboard. You don’t have to use an FTP client or cPanel to access your site’s files.

First, you’ll need to install and activate the WP File Manager plugin. If you need help, then please see our guide on how to install a WordPress plugin.

Upon activation, you can head to WP File Manager from your WordPress admin panel.

Next, you’ll need to select the ‘public_html’ folder from the panel on the left. After that, you can scroll down and navigate to the ‘php.ini’ file.

View php.ini file in file manager plugin

Once you’ve located the file, simply right-click to download it onto your computer.

3. Finding php.ini Path in WordPress using the phpinfo.php File

You can also find the php.ini file by creating a phpinfo.php file and placing it in the root directory of your WordPress installation.

This is a slightly advanced method and is recommended for people who know how to use an FTP client and access the root directory of a website.

First, you’ll need to create a new text editor file. You can use Notepad, Bracket, Sublime Text, or any similar software to create one. In the file, ensure that you enter the following code:

<?PHP phpinfo(); ?>

Next, you’ll need to save the file and name it phpinfo.php. You can use any other name, but make sure that there is ‘.php’ at the end.

After that, you will need to use an FTP client to access the root directory of your website and upload the file. Simply drag the phpinfo.php file from the left panel and drop it into your site’s root directory.

If you need help, then please see our guide on how to use FTP to upload files to WordPress.

Next, you will need to enter the following web address in your browser:

www.example.com/phpinfo.php

Just make sure that you replace the ‘example.com’ with your domain name.

From here, you’ll see details about PHP installation on your site and the path for locating the php.ini file.

To find the path of the file, you can look for the ‘Configuration File Path’ or ‘Loaded Configuration File’ fields.

You’ll see the path for the php.ini file in either one of the fields.

Once you know the path, you can access your site’s files using an FTP client.

From there, simply go to the path you just discovered and download the php.ini file.

Access path of php ini file and download it

Editing the php.ini File in WordPress

Now that you know the location of the php.ini file, the next step is to download and edit it.

Go ahead and open the file in Notepad or any other text editor.

Next, you can edit the file to improve your site’s performance. Here are a few common configurations you can make in the php.ini file:

max_execution_time – This is the time needed to run commands and execute scripts. You can increase the default time of 60 to a higher number if you’re uploading large files to the server.
memory_limit – It relates to the memory needed to upload files and execute commands. Editing the memory limit will help you accommodate long content and lots of images. By default, it is set to 256M, but you can increase the memory limit.
upload_max_filesize – Editing this option allows you to upload large media files and increase the limit.
post_max_size – If your blog posts contain a lot of images and videos, then the size of the post will increase. To avoid any errors, you can increase the post_max_size to accommodate more extensive articles.

Once you’ve made these changes to the php.ini file, you can simply upload it back to your server in the same location using the cPanel, an FTP client, or the file manager plugin.

We hope this article helped you learn where is php.ini in WordPress and how to edit it. You may also want to see our guide on the most common WordPress errors and the best WordPress plugins.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post Where Is php.ini in WordPress? (& How to Edit This File) first appeared on WPBeginner.

June 21, 2023

Round Up: 18 Free Plugins to Help Troubleshoot and Debug WordPress

I’ve written numerous tutorials explaining how to troubleshoot WordPress, plugins, email, and more. When investigating issues, diagnosing problems, and hunting bugs, troubleshooting is a critical core skill for any web developer. To help readers level up their tool belt, here’s a quick round-up of free plugins to help troubleshoot any of your WordPress projects.

Plugins to troubleshoot & debug WordPress

There are TONS of great troubleshooting plugins available at the WordPress.org Plugin Directory. Some of these plugins you’re probably familiar with, others are newer with their own unique features. While nobody is gonna need all of these plugins, it is comforting that there are so many to choose from. So you can find the best tools for whatever inspecting or debugging is needed. Plus all of these plugins are open source and 100% free. So without further ado..

★ BugFu Console Debugger: Handy plugin that enables logging of PHP directly via the browser console. Can be a huge time saver for developers.
★ Code Profiler: Measures the performance of your plugins and themes at the PHP level. Finally a replacement for the once-great P3 Profiler.
★ Debug: Handles the configuration of debug and other variables via wp-config.php. So you don’t have to edit the file manually.
★ Debug Bar: Adds a debug menu to the admin bar that shows query, cache, and other debugging information. Super useful tool for analyzing performance.
★ Debug Info: Provides important details about your WordPress operating environment. Easy way to get PHP configuration (via phpinfo()).
★ Debug Log Manager: Provides all sorts of tools for managing your site’s debug logs and more. Another massive time-saving tool.
★ Debug This: Displays lots of details about your WordPress site via the admin bar. Reveals “under the hood” what’s happening on each page.
★ Log HTTP Requests: Incredibly useful plugin for measuring and logging outgoing HTTP requests. One of my favorite plugins when developing.. other plugins :)
★ Plugin Detective: Holds your hand through the process of troubleshooting your site. Could be super useful depending on your workflow.
★ Query Monitor: Enables debugging of database queries, PHP errors, hooks, and much more. Hands down one of the best plugins for debugging WordPress.
★ System Dashboard: Monitors WordPress components, processes, server hardware, software, and resource usage. A must-have for serious WordPress developers.
★ Variable Inspector: Enables you to inspect various PHP variables via the dashboard in the WP Admin Area. Huge time-saver when working with PHP variables.
★ WP Console: Adds PsySH runtime developer console, interactive debugger and REPL. Write code and view the output right in your browser.
★ WP Crontrol: Enables you to view and control what’s happening in the WP-Cron system. Excellent plugin and highly recommended.
★ WP Debug Log: Enables you to check the debug log from the dashboard and optionally send email notifications. Looks super useful for debugging with WordPress.
★ WP Debugging: Adds the requisite PHP constants to the wp-config.php file to enable debugging. So you don’t have to edit the file manually.
★ WPPerformanceTester: Measures performance of your WordPress site. Looks interesting and useful but hasn’t been updated in a while.
★ WordPress Hosting Benchmark tool: Tests the performance of your server and compares with results from other servers. A great tool for diving deeper into server performance.
★ Explore even more debug tools..: The WP Plugin Directory is loaded with many plugins for developing, troubleshooting, and debugging your site. Try a few searches and browse the results. All free and open source. Amazing.

Shouts out to the developers working to provide these free tools to the WordPress community. Your work is important and appreciated.

Note: WordPress plugins tend to change over time, usually for the better but not always. So to be safe, make sure to check the official homepage/docs for more details before trying any of the above plugins. If anything should or should not be on the list, please let us know so we can update the post. Thank you!

Props

Gotta give props here. I was inspired to put this round up together after seeing this post in David McCan’s Dynamic WordPress group on Facebook. Check it out for some interesting comments and more ideas for troubleshooting your WordPress-powered websites.

Cheers! 😎

June 14, 2023

PHP or ASP.NET: Which Powerhouse Platform Prevails for Your Next Project?

When it comes to web development, choosing the right platform is crucial. PHP and ASP.NET are two of the most popular options, but which one is the best fit for your project? In this article, we'll explore the strengths and weaknesses of both platforms to help you make an informed decision.

But before we dive into the details, let's start with a brief introduction. PHP is an open-source scripting language that is widely used for web development. It's known for its flexibility, ease of use, and extensive community support. On the other hand, ASP.NET is a web application framework developed by Microsoft. It's based on the .NET framework and supports multiple programming languages, including C# and Visual Basic.

June 7, 2023

Becoming a Skilled PHP Developer: A Comprehensive Guide

In today's technology-driven world, web development has become an essential skill set for aspiring programmers. PHP (Hypertext Preprocessor) is one of the most widely used and versatile programming languages for web development. Mastering PHP not only opens up a plethora of career opportunities but also equips you with the ability to create dynamic and interactive websites and applications. This guide will outline the key steps to becoming a good PHP developer.

Top 13 Tips To Becoming a Skilled PHP Developer

"Learn the fundamentals, master PHP syntax, embrace best practices, and collaborate to become a skilled PHP developer."

May 17, 2023

Generating Database Seed Files with ChatGPT

Frameworks like Laravel and Ruby on Rails eliminate countless decisions that you would otherwise be forced to make when building web applications. Even so, a great deal of time is spent on mundane tasks rather than building the intellectual property...

The post Generating Database Seed Files with ChatGPT appeared first on Treehouse Blog.

February 20, 2023

What Is the JavaScript Equivalent To The PHP sleep() Function?

JavaScript does not have a direct equivalent to the PHP sleep() function, which pauses the execution of a script for a specified number of seconds. However, there are a few ways to achieve similar functionality in JavaScript.

UNLIMITED DOWNLOADS: Email, admin, landing page & website templates

Starting at only $16.50 per month!

Using `setTimeout()`

The setTimeout() function is a built-in JavaScript function that allows you to run a piece of code after a specified amount of time. You can use it to create a delay in your script. Here’s an example:

console.log('Before Sleep');
setTimeout(() => {
  console.log('After Sleep');
}, 3000);

In the example above, the console.log('Before Sleep') statement will be executed immediately, followed by a 3-second delay, after which the console.log('After Sleep') statement will be executed.

Using `async/await`

Another way to create a delay in JavaScript is to use the async/await syntax. With async/await, you can write asynchronous code that runs in a way that is similar to synchronous code. For example:

async function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

async function main() {
  console.log('Before Sleep');
  await sleep(3000);
  console.log('After Sleep');
}

main();

In this example, we’ve created an async function called sleep that returns a Promise that resolves after a specified amount of time. The main function uses the await keyword to wait for the sleep function to complete, effectively creating a 3-second delay.

Note that async/await is only supported in modern browsers and requires a runtime with support for Promises.

Both of these methods can be used to achieve a similar result to the PHP sleep() function, but with different syntax and limitations. Choose the method that works best for your use case.

Further reading.

February 13, 2023

How To Get a User’s IP Address With PHP

In PHP, there are several methods to retrieve a user’s IP address. We will explore two of those ways in this article.

UNLIMITED DOWNLOADS: 500,000+ WordPress & Design Assets

The most reliable way to get a user’s IP address in PHP is to use the $_SERVER superglobal variable.

The $_SERVER superglobal variable contains information about the server environment, including the user’s IP address. Here’s an example:

<?php
$ip = $_SERVER['REMOTE_ADDR'];
echo $ip;
?>

The $_SERVER['REMOTE_ADDR'] element returns the IP address of the client (i.e., the user’s device) that is making the request to the server. This method works well for most cases, but there are a few situations where it may not return the correct IP address, such as when the user is behind a proxy server or using a VPN.

To handle these cases, it is recommended to use the following code to get the user’s IP address:

<?php
function get_client_ip() {
    $ip = '';
    if (isset($_SERVER['HTTP_CLIENT_IP'])) {
        $ip = $_SERVER['HTTP_CLIENT_IP'];
    } elseif (isset($_SERVER['HTTP_X_FORWARDED_FOR'])) {
        $ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
    } else {
        $ip = $_SERVER['REMOTE_ADDR'];
    }
    return $ip;
}

$ip = get_client_ip();
echo $ip;
?>

In this code, we first check if the $_SERVER['HTTP_CLIENT_IP'] element is set. If it is, we use its value as the user’s IP address. If not, we then check if the $_SERVER['HTTP_X_FORWARDED_FOR'] element is set. If it is, we use its value as the user’s IP address. If neither of these elements is set, we use the $_SERVER['REMOTE_ADDR'] element as the user’s IP address.

This method provides a more robust solution for retrieving the user’s IP address, as it takes into account the possibility that the user may be behind a proxy server or using a VPN.

Learn more here.

January 30, 2023

PHP vs React

When it comes to building a new project, choosing the right technology can make all the difference in its success. Two popular technologies in the software development world are PHP and React.

Both have their own strengths and weaknesses, and choosing the right one for your project can be a difficult task.

January 29, 2023

Stay Logged in to WordPress

I work from home so can afford to leave tabs open for each of my WordPress sites. That way I can jump on anytime and update or add new content very quickly. The problem I kept running into is that WordPress automatically logs out users after 48 hours. Which means I have to log back in every day even when it’s not necessary. So I needed a way to stay logged in to WordPress indefinitely. Fortunately WordPress is very flexible and easy to customize, and the login duration can be changed via several different methods.

Here are three easy ways to stay logged in to WordPress for a longer period of time.

Check the box

The easiest way to increase the expiration date/time for logins, is to simply check the “Remember Me” checkbox when logging in to WordPress. That will increase the expiration to 14 days, or whenever the browser is closed. After that time, the session cookie expires and you’ll need to log in once again.

This is useful if 14 days is enough time for your workflow.

One downside is that it requires an extra click to check the box. Fine I guess if you’re logging in manually. But if you’re using a password manager or other auto-login app, the extra checkbox step requires action on your part, thus adding friction and slowing things down.

Another downside is that 14 days is not always enough. For my own workflow, I prefer to minimize as many needless steps as possible. So I prefer the next method of extending the login duration, using a slice of custom code..

Add custom code

For more flexibility and less friction, you can add the following code snippet to stay logged in to WordPress for however long is necessary, even indefinitely if it makes sense to do so. This is the preferred technique for my own websites.

Important: Be mindful of any other users who may be logging in on public machines. Only extend the login duration if you know 100% that it’s safe and secure.

Here is the magic code to stay logged in to the WordPress Admin Area. You can add this code via your theme functions file, or add via simple custom plugin. Here is a guide that explains how to do both.

function shapeSpace_stay_logged_in($expires) {
	
	return 172800; // default 48 hours
	
}
add_filter('auth_cookie_expiration', 'shapeSpace_stay_logged_in');

As written, this code hooks into auth_cookie_expiration and filters the expiration duration (in seconds). By default the duration is 48 hours. You can change that to anything that works best.

To stay logged in forever, change the interval to some very large number, like 3153600000 to stay logged in for 100 years ;) To help with converting time to seconds, you can use a free time conversion calculator.

Thanks to Alex Mills (Viper007Bond) for sharing this code at Stack Exchange.

Install a plugin

If you want to extend the login beyond 14 days, but don’t want to go the custom code route, installing a plugin is the way to go. Currently there seems to be only a couple of capable plugins in the WP Plugin Directory:

Let me know if I’ve missed anything! :)

January 20, 2023

How to Import Content in WordPress in 7 Simple Steps

Importing content in WordPress is simple when you use WordPress with Hostinger because it’s easy to get started and ensures you have the right capacity to manage your content. Start using WordPress with Hostinger now for $1.99 per month.

WordPress is the world’s most popular CMS platform for a good reason. It’s an excellent option for blogging or any other type of content-heavy site. Switching to WordPress is a great idea if you run a website on another platform.

But switching to WordPress doesn’t mean you have to start from scratch. You can simply import the content from your existing site to your new WordPress website. This step-by-step guide will walk you through that process.

The Top Tools to Import Content in WordPress

Our team here at Quick Sprout has extensively researched the best tools to import content in WordPress. Take these into consideration as you’re going through this process.

WordPress with Hostinger — Best overall
Wix — Best for beginners building a professional blog
Squarespace — Best for artists and designers
LinkedIn — Best for networking
Medium — Best for writing to a built-in audience

Import Content to WordPress in 7 Easy Steps

Importing content in WordPress might seem like a daunting task at first glance. But it’s actually fairly simple, and the entire process can be summarized in the seven easy steps below:

Sign Up For WordPress with Hostinger
Backup Your Site Files and Databases
Make Sure You Have Sufficient Memory Space for the Import
Identify Where You’re Importing Content From
Export and Review the File You Want to Import
Configure a New WordPress Import
Backup Your New WordPress Content

The bulk of this guide will focus on using WordPress with Hostinger to complete these steps. That’s because Hostinger offers WordPress-specific hosting plans at an affordable rate with all the tools and features you need to seamlessly import your content and continue running your WordPress site with success in the long run. Get started today with WordPress and Hostinger for just $1.99 per month.

The first thing you need to do is sign up for WordPress. Unlike other website platforms, WordPress is only a CMS—meaning it does not have web hosting built into the system. So for your site to be live on the web, you also need to secure a web hosting solution during this step.

While there are dozens of different routes you can take here, using WordPress with Hostinger is by far the best and simplest choice. This is especially true if you’re starting a brand new WordPress site and importing content from another site.

One of the top reasons why Hostinger is ideal for this process is because they offer WordPress-specific hosting packages, so your hosting solution is optimized for WordPress out-of-the-box, and it comes with all of the great features you need to run a successful WordPress site.

Hostinger for WordPress-Powered Websites webpage — Hostinger’s WordPress plans simplify the content import process.

All of these plans come with a one-click WordPress installer. You’ll also benefit from 24/7 WordPress support by the experts at Hostinger. So if you have any questions or need help during this process, they’re just a click away via live chat.

It’s also worth noting that every WordPress hosting plan from Hostinger comes with a free migration. So if you’re moving your site from another web host, they’ll take care of the technical complexities for you as your site gets transferred to its new servers.

Best of all, this option is affordable for anyone. Hostinger’s WordPress plans start at just $1.99 per month. All purchases are backed by a 30-day money-back guarantee.

Once you’ve signed up for Hostinger and installed WordPress, you can proceed with the remaining content import steps.

Step 2 – Backup Your Site Files and Databases

Next, you need to switch over to the platform where your content currently lives. It could be a website platform or another CMS, and this step will look a little different for everybody.

Regardless of where your content is, the platform should have some type of documentation that explains how to back up the data. In some instances, this will be handled for you automatically on a nightly or weekly basis, and other platforms require manual backups or third-party plugins.

While importing content into WordPress is generally safe and should not impact the data that’s hosted elsewhere, it’s always a good practice to back up your files before proceeding. Weird things can happen, and it’s better to be safe than sorry.

So if something goes awry during the import process, you can always restore the content from your latest backup.

Make sure the backup includes all of your website files and MySQL databases. This can typically be handled directly from your website platform or web host’s control panel.

Let’s say you were already using Hostinger to power another WordPress site. This process would be as simple as navigating to the Backup Wizard on your cPanel.

Example of cPanel with red arrow pointing to Backup Wizard button — Backing up your files helps keep your data safe in case something goes wrong during the import.

From here, you can generate full backups, partial backups, and even download your backups with just a few clicks. There’s a good chance that whatever platform you’re using also has a similar backup feature that should be easily accessible.

Step 3 – Make Sure You Have Sufficient Memory Space for the Import

This next step requires you to do two things. First, you have to check the size of the content you’re going to import. Then you must verify that the file size is less than the allowed memory space for your import.

If the import is too big, you’ll get an error message or fatal error code from your servers. Even if the import fails, some of your files might be partially imported to WordPress. This can be problematic when you try again a second time, as you’ll end up with duplicate data.

That’s why it’s so important to verify your memory space before you attempt a new import.

Be aware that your maximum file upload size may not necessarily be the same as the SSD storage that’s offered in your selected plan from your hosting provider.

Start by going to the backup that you generated in the previous step. You should see the file size displayed if you download it or attempt to download it.

To check or modify your maximum file upload size via Hostinger, simply navigate to your PHP Configuration and select PHP options.

Example of Hostinger's Advanced screen with red boxes around PHP Configuration and PHP options buttons — Hostinger makes it easy to adjust your max file upload size through the PHP Configuration.

By default, there’s a good chance this will be set to 512 MB. But you can adjust it as needed. Make sure you adjust both the uploadMaxFilesize and postMaxSize fields.

If you’re uncomfortable doing this alone, you can always contact Hostinger’s support team for assistance. They’ll likely be able to change this for you on your behalf. Just let them know the file size that you’re going to import, and they’ll ensure the space is sufficient.

Step 4 – Identify Where You’re Importing Content From

To simplify imports, WordPress has several built-in importers. This is a great option for those of you who are importing specific posts or comments that are currently hosted on other platforms.

Those options include:

Blogger — Use this tool to import posts, comments, and users from your Blogger site to WordPress.
Blogroll — This tool imports links using OPML formatting.
Categories and Tags Converter — Allows you to bring your existing content categories and tags to WordPress.
LiveJournal — You can use the LiveJournal API to import posts in WordPress.
Movable Type and Typepad — Import blog posts and comments on either of these blog platforms.
RSS — Use your current blog’s RSS feed to import content in WordPress.
Tumblr — Move posts and other media from Tumblr to WordPress using the Tumblr API.
WordPress — If you’re moving content from one WordPress site to another, you can import posts, pages, comments, categories, tags, and custom fields directly from an exported WordPress file.

The steps for each of these options are different. But it’s as simple as following the instructions on the screen as you’re prompted. If your content currently lives on one of the platforms above and you’d like to proceed using one of these methods, navigate to Tools on the left side of your WordPress dashboard and select Import from the expanded menu.

WordPress dashboard with Tools selected and Import screen displayed — The Tools import screen is an easy way to import content in WordPress.

Before you proceed, there are a few things you should know. First, if you’re importing content from one WordPress site to another, your web host should be able to help you.

Hostinger offers free site migrations, which bring your site from your current servers to their servers. Depending on your situation, the migration alone could help you bypass some of the import steps. So it’s always in your best interest to check with your web host to see if they can save you from going through unnecessary steps or handle some or all of the importing on your behalf.

If you don’t see the importer on this page that matches where your content is coming from, there’s no need to panic. You can always install a WordPress plugin to facilitate the import. This can either be a plugin offered directly by the provider you’re currently using or a third-party plugin that works as an intermediary between multiple platforms and WordPress.

This option all depends on the type of content you’re trying to import.

For example, some options will be better for blogs and comments, while others will be better for importing users, customer information, media, and widgets.

Step 5 – Export and Review the File You Want to Import

If you’re not going to connect through an API or direct importer, you should be able to export your existing content via XML or CSV file.

This is typically a better option for larger sites, as using plugins can create some errors. So a manual import can give you more control over exactly what you’re importing and how it’s formatted.

Again, this step will look different for everyone. It all depends on where your current content is located. If you’re unsure how to export that content, there should be sufficient documentation for you to follow directly from that provider.

Step 6 – Configure a New WordPress Import

Once your file is ready, go back to WordPress. You can use the WP All Import Plugin to configure your content after the import is completed.

This plugin is regularly updated and has more than 200,000 active installations.

From your WordPress dashboard, you can navigate directly to the plugin. Then drag and drop the file you exported in the previous step.

The cool part about using this plugin is that it does more than just add your files and content to WordPress. It also gives you the ability to configure how everything looks once it’s moved over.

WP All Import Drag & Drop screen — Configuring your content is easy and doesn’t require any technical expertise with this plugin.

This step helps ensure that the formatting in your XML or CSV file doesn’t get messed up during the import. Things like this could easily happen if the header title on a single column doesn’t align with what you want.

This plugin allows you to create WordPress content using the format and template you create now. Then you can choose which type of data to include with the import.

For example, maybe you want to import everything, or maybe you only want the blog posts and images.

Step 7 – Backup Your New WordPress Content

Once the import is complete, make sure you back up your WordPress site.

Every Hostinger plan supports weekly backups. If you upgrade to a Hostinger Business WordPress plan or higher, you’ll benefit from automated daily backups.

If you’re on a lower-tiered plan, you shouldn’t risk waiting a week for the next backup. Instead, you can generate a new backup manually directly from your Hostinger account.

Simply click on Manage and select Backups from the sidebar. Then click Generate new backup.

Hostinger Backups Screen with red arrow pointing to "Select" button under "Generate new backup" — Creating a manual backup keeps your newly imported content safe.

Now you’re done! You can repeat this process as needed any time you want to import new content in WordPress.

Final Thoughts About Importing Content in WordPress

Successfully importing content in WordPress all starts with the right web hosting solution. Using a WordPress-specific plan, like Hostinger, will simplify the process and ensure you have all the tools at your fingertips to import content without losing data.

Keeping backups of your content is also crucial to avoid data loss. If you have a large file to import, make sure your plan has enough memory and storage space to accommodate your import. Just follow the step-by-step instructions in this guide, and you’ll be all set.

December 5, 2022

Securing Developer Tools: A New Supply Chain Attack on PHP

Supply chain attacks are a hot topic for development organizations today. Last year, in the largest ever software supply chain attack, a backdoor infected 18,000 SolarWinds customers. Earlier this year, a security researcher was able to breach Apple, Microsoft, PayPal, and other tech giants using a new supply chain attack technique.

The underlying design exploited by these attacks is that all modern software is built on top of other third-party software components, often without clear visibility of all the downloaded packages. And while reusing many components allows to speed up the development process, infecting the supply chain is a very effective and subtle attack vector to compromise many organizations at once.

November 28, 2022

PHP vs. JavaScript: Comparisons and Applications

PHP and JavaScript are two very popular programming languages and there are many web apps that use them both at the same time. The main difference is that, while PHP is only for back-end development, JavaScript is used for front-...

The post PHP vs. JavaScript: Comparisons and Applications appeared first on Treehouse Blog.

November 16, 2022

mentions with PHP implode

Hi,This code creates a friendly link on user mentions in comments...

However, it is not case sensitive and vice versa.

Examples;

@test works
@Test doesn't work

The regular expression takes both values. But the query is not catching. I figured it would be a case-sensitive collation on the database. But I am using utf8_general_ci (users) & utf8_unicode_ci (comments)... I tried changing it to utf8mb4_bin, but it's still the same. The same (user mentioned) only because of a lowercase / or uppercase letter it doesn't work ;/
What do I do?

November 16, 2022

doubt about mentions with PHP implode

Hi,This code creates a friendly link on user mentions in comments...

However, it is not case sensitive and vice versa.

Examples;

@test works
@Test doesn't work

What do I do?

text = "@test @Test";

$pattern = "/\@(\w+)/"; preg_match_all($pattern,$text,$matches);
if($matches){  

$sql = "SELECT * FROM users WHERE username IN ('" .implode("','",$matches[1]). "')"; $user = $link->query($sql);

foreach($user as $i=>$u){
$text = preg_replace("/@".$u['username']."\b/",
"<a href='#' title='{$u['user_id']}'>@{$u['username']}</a> ", $text);
}
echo $text;
}

September 29, 2022

An In-Depth Guide to PHP 8.1: Enums

Enums or enumerations are a new feature introduced in PHP 8.1 that contains a defined number of possible values you can use. When creating an app, you often come across scenarios where you have a predetermined list of options to select from, for instance:

A blog entry can be published, in the draft, or in review.
A player may be a medic, soldier, engineer,
A ticket may be VIP, standing, or seated,
and so on ...

1. Using The WordPress Playground URL

2. Using The GitHub Repository

3. Using wp-now In The Command Line

4. Using The Visual Studio Code Extension

5. Using A Chrome Extension To Preview Themes & Plugins

Sharing With The Query API

Sharing With An Embedded iFrame

Sharing With JSON Blueprints

References & Resources

Creating Block Patterns in WordPress 6.2

Registering Custom Block Patterns With PHP

Registering Custom Block Patterns Via The /patterns Directory

Creating Synced Patterns

Creating Standard, Unsynced Patterns

Registering Custom Patterns With register-block-pattern()

Custom Template With Starter Patterns

Using Patterns In The Post Editor

Further Reading

High-Level Programming Languages

1. Abstraction Level

2. Readability and Ease of Use

3. Portability

4. Productivity

5. Examples

6. Performance

Low-Level Programming Languages

1. Abstraction Level

2. Readability and Ease of Use

3. Portability

4. Productivity

5. Examples

6. Performance

Use Cases and Trade-Offs

High-Level Languages

Low-Level Languages

Translating Between High-Level and Low-Level Languages

Choosing Between High-Level and Low-Level Languages

What is php.ini file in WordPress?

Why Do You Need to Edit php.ini File in WordPress?

Finding the php.ini File Location in WordPress

1. Use cPanel to Locate the php.ini File

2. Locate the php.ini File using a File Manager Plugin

3. Finding php.ini Path in WordPress using the phpinfo.php File

Editing the php.ini File in WordPress

Plugins to troubleshoot & debug WordPress

Props

Top 13 Tips To Becoming a Skilled PHP Developer

UNLIMITED DOWNLOADS: Email, admin, landing page & website templates

Using setTimeout()

Using async/await

UNLIMITED DOWNLOADS: 500,000+ WordPress & Design Assets

Three ways to do it..

Check the box

Add custom code

Install a plugin

The Top Tools to Import Content in WordPress

Import Content to WordPress in 7 Easy Steps

Step 1 – Sign Up For WordPress with Hostinger

Step 2 – Backup Your Site Files and Databases

Step 3 – Make Sure You Have Sufficient Memory Space for the Import

Step 4 – Identify Where You’re Importing Content From

Step 5 – Export and Review the File You Want to Import

Step 6 – Configure a New WordPress Import

Step 7 – Backup Your New WordPress Content

Final Thoughts About Importing Content in WordPress

3. Using `wp-now` In The Command Line

Registering Custom Block Patterns Via The `/patterns` Directory

Registering Custom Patterns With `register-block-pattern()`

Using `setTimeout()`

Using `async/await`