WordPress, often touted as the world’s most popular content management system (CMS), has transformed the way we build and manage websites. What began as a simple blogging platform has evolved into a versatile and robust tool used by individuals, businesses, and organizations of all sizes. In this post, we’ll explore why WordPress is the go-to choice for so many and why you should consider it for your website.
1. User-Friendly and Accessible:
One of the most significant advantages of WordPress is its user-friendly interface. Whether you’re a seasoned developer or new to website creation, WordPress caters to all skill levels. The intuitive dashboard, with its easy-to-navigate menus, allows you to manage content, add pages, and customize your website effortlessly. No coding experience? No problem. The wealth of plugins and themes make it possible to create a professional website without writing a single line of code.
2. A World of Themes and Plugins:
The heart of WordPress lies in its vast library of themes and plugins. Themes provide the visual design of your website, and with thousands to choose from, you can create a site that matches your vision. Whether you’re building a blog, e-commerce store, portfolio, or a corporate website, you’re sure to find a theme that suits your needs.
Plugins are the secret sauce that adds functionality to your site. From SEO optimization to e-commerce features, there’s a plugin for almost anything. These extensions make it easy to expand your site’s capabilities without needing to be a coding expert.
3. SEO-Friendly:
WordPress is inherently search engine optimization (SEO) friendly. It offers features like customizable permalinks, meta descriptions, alt tags, and more, helping your site rank higher in search engine results. If you’re serious about improving your site’s visibility, you can easily find SEO plugins to fine-tune your strategy.
4. Strong Community and Support:
WordPress boasts a massive and passionate community. With countless forums, blogs, and experts willing to share their knowledge, help is never far away. Troubleshooting issues or seeking advice is a breeze with this network of enthusiasts.
5. Scalability and Flexibility:
Whether you’re starting a personal blog or launching a full-fledged e-commerce site, WordPress can grow with you. It’s easy to scale your site as your needs change. With custom post types, you can tailor content to fit your specific requirements.
If you’re searching for a dedicated WordPress professional to bring your website dreams to life, look no further. I’m Muhammad Faizan Haidar, a seasoned WordPress plugin developer and WordPress core contributor with 5 years of experience in building custom Plugins, Themes, and Websites.
My passion for WordPress goes beyond just building websites. I’m committed to creating solutions that meet your unique needs, whether it’s developing a custom plugin, designing a tailored theme, or optimizing your site for peak performance. My experience in the WordPress ecosystem allows me to deliver results that not only look great but also function flawlessly.
Conclusion:
WordPress is more than just a CMS; it’s a dynamic platform that caters to the needs of its users. Whether you’re a novice or a pro, its flexibility, support, and massive library of themes and plugins make it a standout choice for website creation. If you’re considering a website project, WordPress is the all-encompassing tool that’s got your back.
Share Your Thoughts:
Have you had experience with WordPress? What do you find most appealing about this platform? Share your thoughts and experiences in the comments below.
This blog will help WordPress developers to overcome the hurdles. That they will face while using WP List Table inside a metabox within a post/cpt.
WPCS & WP List Table
Being a big follower of WPCS and WP List Table class being a core functionality. And easy to extend I always prefer to use it for custom listings so I don’t have to take care of the core standards.
Open source contribution
First I tried it 2 years ago in my WordPress open source plugin Attendance Management For LifterLMS .( To see which approach I do use to develop a plugin please click here ). Please see the attachment below.
But at that time I was not using any bulk actions so I used it just for displaying attendances count. But I had an issue while saving/updating that post. As it kept redirecting to the edit.php each time I save or update the post. After surfing the google and trouble shooting. I solved the problem by overriding the following function in the derived class.
/**
* Generate the table navigation above or below the table.
*
* @since 1.0.0
* @access protected
*
* @param string $which
*/
protected function display_tablenav( $which ) {
// REMOVED NONCE -- INTERFERING WITH SAVING POSTS ON METABOXES
// Add better detection if this class is used on meta box or not.
/*
if ( 'top' == $which ) {
wp_nonce_field( 'bulk-' . $this->_args['plural'] );
}
*/
?>
<div class="tablenav <?php echo esc_attr( $which ); ?>">
<div class="alignleft actions bulkactions">
<?php $this->bulk_actions( 'bottom' ); ?>
</div>
<?php
$this->extra_tablenav( $which );
$this->pagination( $which );
?>
<br class="clear"/>
</div>
<?php
}
Debugging WP List Table
Above function was generating an extra nonce. Which was manipulating post’s default nonce so it never reached to the save process. By overriding this function and commenting out the nonce part it worked for me as now save/update was working fine. But I was still having issue with my list table search method. When I clicked on the search button WordPress gets it as a call to save the post. So it takes to the save post method. And I lost my search parameters after redirection to the same post. So after troubleshooting I found a trick and that was the save post hook.
The issue was, when clicking the search submit button it redirected to the same post with a post_updated message. What happens here is basically post_update hook fires. Which redirects to the same post and I can’t get the search query_args. What I did is, I captured the update and post save hook and added query_args. Then redirected to the respective post and hence it worked. WP List table search box input has name “s” so we have to look for “s”( $_GET[“s”], $_POST[“s”] ) Find the code below please:
So that worked back then. But recently I was developing a plugin for my client. And I wanted to display some details to a custom post type. Again I encountered the same problem but this time what I was using extra was bulk action functionality. I was only having this issue when I was using the bulk actions. So I knew that the issue is with bulk actions.
So I started debugging bulk_actions( $which = ” ) function. And finally found that the issue was with the following line of code.
The select filed has a name attribute which after calculation is equal to action or action2 and on save post this $_POST[‘action’] == ”some-action” but WordPress save post is not expected to receive this value. So that’s why it redirects to the edit.php. I resolved this just by changing the name attribute of the select to any desired value. Like in my case I changed it to actions i.e. name=”actions”.
Now lets discuss the ways to handle bulk actions. In same post update/save hook you will find actions and other required data in $_POST either you can redirect to same edit page by adding query parameters and look for these parameters in your list table class and process bulk actions or you can just process bulk actions is same save/update hook and see updated results.
WP List Table Code compatible with MetaBoxes
Please find the whole working code below. You can use in your metabox on any post type by changing it according to your needs.
What is Plugin Boiler Plate? A foundation for WordPress Plugin Development that aims to provide a clear and consistent guide for building your plugins.
Every time I start working on a new plugin I find myself renaming files names, searching and replacing plugin-name, Plugin_Name , the packages, sub packages names, etc. All these tasks take me around 5-10 minutes every time, and I don’t like repeat unnecessary tasks.
So I found an easy way to generate WordPress plugin basic structure with in seconds. Of course it saved a lot of time.
Please visit WordPress Plugin Boilerplate to generate plugins boiler plate. Obviously it won’t generate all of the files you require for your plugin. You can add more files once you have your basic structure.
There is no standard way to write a plugin. People follow different ways to write plugins. Some plugins require OOP to be followed and some don’t. But this is the best OOP structure that I had ever found and used in my Plugins development.
It is meant to be a starting point for plugin development, an object oriented way of creating a standardized plugin. Since it is coded with OOP principles, it is mainly intended for intermediate coders, but you can easily use it even as a beginner if you know what goes where. By the end of this article, you should know what’s what and how you can get started with it – regardless of your coding experience. Lets dig deeper into it.
File Structure. The boilerplate is meant to be used as a GitHub repository, so the main directory contains files commonly found in GitHub repos. The README.md file is a general readme and shows up on your main repository page as the description and details about the plugin. The .gitignore file is for setting files that git should ignore when working with files. The main folder here plugin-name is where the plugin is stored. It should have at least one fine your-plugin-slug.php with all the plugin details (Plugin Name, Version, Description, Author, Plugin Slug).
<?php
/**
* The plugin bootstrap file
*
* This file is read by WordPress to generate the plugin information in the plugin
* admin area. This file also includes all of the dependencies used by the plugin,
* registers the activation and deactivation functions, and defines a function
* that starts the plugin.
*
* @link www.authoruri.com
* @since 1.0.0
* @package Your_Plugin_Slug
*
* @wordpress-plugin
* Plugin Name: Your Plugin Name
* Plugin URI: www.yourpluginurl.com
* Description: This is a short description of what the plugin does. It's displayed in the WordPress admin area.
* Version: 1.0.0
* Author: Author Name
* Author URI: www.authoruri.com
* License: GPL-2.0+
* License URI: http://www.gnu.org/licenses/gpl-2.0.txt
* Text Domain: your-plugin-slug
* Domain Path: /languages
*/
// If this file is called directly, abort.
if ( ! defined( 'WPINC' ) ) {
die;
}
/**
* Currently plugin version.
* Start at version 1.0.0 and use SemVer - https://semver.org
* Rename this for your plugin and update it as you release new versions.
*/
define( 'YOUR_PLUGIN_SLUG_VERSION', '1.0.0' );
/**
* The code that runs during plugin activation.
* This action is documented in includes/class-your-plugin-slug-activator.php
*/
function activate_your_plugin_slug() {
require_once plugin_dir_path( __FILE__ ) . 'includes/class-your-plugin-slug-activator.php';
Your_Plugin_Slug_Activator::activate();
}
/**
* The code that runs during plugin deactivation.
* This action is documented in includes/class-your-plugin-slug-deactivator.php
*/
function deactivate_your_plugin_slug() {
require_once plugin_dir_path( __FILE__ ) . 'includes/class-your-plugin-slug-deactivator.php';
Your_Plugin_Slug_Deactivator::deactivate();
}
register_activation_hook( __FILE__, 'activate_your_plugin_slug' );
register_deactivation_hook( __FILE__, 'deactivate_your_plugin_slug' );
/**
* The core plugin class that is used to define internationalization,
* admin-specific hooks, and public-facing site hooks.
*/
require plugin_dir_path( __FILE__ ) . 'includes/class-your-plugin-slug.php';
/**
* Begins execution of the plugin.
*
* Since everything within the plugin is registered via hooks,
* then kicking off the plugin from this point in the file does
* not affect the page life cycle.
*
* @since 1.0.0
*/
function run_your_plugin_slug() {
$plugin = new Your_Plugin_Slug();
$plugin->run();
}
run_your_plugin_slug();
Activation, Deactivation & Uninstall: This file ( your-plugin-slug.php ) also includes activation and deactivation hooks. These hooks are fired when plugin is activated and deactivated. This file is a gateway to the functionality of the whole plugin. You can add your whole code in this file but its not recommended you should follow MVC separate your models, views and your controllers. Any code you want to run when the plugin is activated should go in includes/your-plugin-slug-activator.php. In this file, there is a class named Your_Plugin_Slug_Activator inside which there is a activate() method you should use.
<?php
/**
* Fired during plugin activation
*
* @link www.authoruri.com
* @since 1.0.0
*
* @package Your_Plugin_Slug
* @subpackage Your_Plugin_Slug/includes
*/
/**
* Fired during plugin activation.
*
* This class defines all code necessary to run during the plugin's activation.
*
* @since 1.0.0
* @package Your_Plugin_Slug
* @subpackage Your_Plugin_Slug/includes
* @author Author Name <author@gmail.com>
*/
class Your_Plugin_Slug_Activator {
/**
* Short Description. (use period)
*
* Long Description.
*
* @since 1.0.0
*/
public static function activate() {
//activation code here
}
}
The code you need to run on deactivation should be placed in includes/your-plugin-slug-deactivator.php. The deactivate() method within the Your_Plugin_Slug_Deactivator is what you’ll need to use.
<?php
/**
* Fired during plugin deactivation
*
* @link www.authoruri.com
* @since 1.0.0
*
* @package Your_Plugin_Slug
* @subpackage Your_Plugin_Slug/includes
*/
/**
* Fired during plugin deactivation.
*
* This class defines all code necessary to run during the plugin's deactivation.
*
* @since 1.0.0
* @package Your_Plugin_Slug
* @subpackage Your_Plugin_Slug/includes
* @author Author Name <author@gmail.com>
*/
class Your_Plugin_Slug_Deactivator {
/**
* Short Description. (use period)
*
* Long Description.
*
* @since 1.0.0
*/
public static function deactivate() {
//deactivation code here
}
}
Do you think this is a bit too complex? I don’t blame you! When you start using object oriented concepts you’ll see the benefit of this over procedural code. If nothing else, it provides a very obvious place to put your code which is in itself a huge help. For uninstallation, the recommended method is to use uninstall.php which is what WordPress Plugin Boilerplate does. Your code should be placed at the very bottom of that file. You should dump everything that your plugin has created it is a sign of good plugin development to clean what is of no use. WordPress will automatically call uninstall.php if found in the plugins main folder. You can also use uninstallation hook.
<?php
/**
* Fired when the plugin is uninstalled.
*
* When populating this file, consider the following flow
* of control:
*
* - This method should be static
* - Check if the $_REQUEST content actually is the plugin name
* - Run an admin referrer check to make sure it goes through authentication
* - Verify the output of $_GET makes sense
* - Repeat with other user roles. Best directly by using the links/query string parameters.
* - Repeat things for multisite. Once for a single site in the network, once sitewide.
*
* This file may be updated more in future version of the Boilerplate; however, this is the
* general skeleton and outline for how the file should work.
*
* For more information, see the following discussion:
* https://github.com/tommcfarlin/WordPress-Plugin-Boilerplate/pull/123#issuecomment-28541913
*
* @link www.authoruri.com
* @since 1.0.0
*
* @package Your_Plugin_Slug
*/
// If uninstall not called from WordPress, then exit.
if ( ! defined( 'WP_UNINSTALL_PLUGIN' ) ) {
exit;
}
//write uninstallation code here.
Adding Hooks
Hooks are handled by WordPress Plugin Boilerplate amazingly, but it may seem a bit unwieldy at first. All your hooks should be placed within includes/class-your-plugin-slug.php. More specifically, inside the Your_Plugin_Slug class, within two methods:
define_public_hooks() when adding a hook that is used on the front-end for public.
define_admin_hooks() when adding a hook that is used on the back-end for admins.
Instead of using add_action() or add_filter() as usual, you’ll need to do things slightly differently. Here is how you add an action.
Here we have a loader class Class Your_Plugin_Slug_Loader that automatically adds actions and filters for us. The first parameter is the name of the hook, the second is a reference to the public or admin object. For public hooks this should be $plugin_public, for admin hooks it should be $plugin_admin. The third parameter is the hooked callback function.
While it seems more convoluted it standardizes the addition of hooks completely, splitting them into two distinct groups in the process.
Public And Admin Content
WordPress Plugin Boilerplate splits hooks into admin/public groups but that’s not all. It splits all your code in the same way by asking you to write public-facing code in the public folder and admin-facing code in the admin folder.
Both folders contain css, js and partials folders. You should place used CSS/JS assets into these folders and write templates and other reusable bits of HTML into the partials folder. It’s okay to create new files in the partials folder, in fact, that’s what it’s there for!
You should write your hooked functions in these folders as well, within the class in the respective directories. When we hooked the display_message function to inti hook above, we told WordPress Plugin Boilerplate where to look for it as well. Since we added this to the public facing side, WordPress Plugin Boilerplate expects it to be defined within the Your_Plugin_Slug_Public class which is in the public folder. Simply create this function within the class and write everything else as required.
Resources And Dependencies: You can add other resources and dependencies in includes folder, admin or public folder depending on the use of that resource.
At first, using WordPress Plugin Boilerplate may seem like a hassle, but it will pay off in the end. You will come back a year later and know where everything is, your plugin development will be standardized across products and other developers will be able to figure out what’s going on as well.
Finally, don’t forget that a plugin providing a simple widget may not need such a framework. While the use of WordPress Plugin Boilerplate won’t slow down your plugin it does clog up the view if all you need is a few simple lines of code!
Cheers!
And if you have enjoyed this post, feel free to share it or subscribe to my newsletter below.
This article will help beginners to get conformable with the terms used within the WordPress ecosystem.
Some of these terminologies might seem known to you depending on your level of experience with WordPress, and web development in general.
These terms will help you to better understand the WordPress official documentation, support articles, and other WordPress developers. Now, here are some terms which you will find handy when talking about WordPress .
Back End – The back end refers to the area of your site where you can log in and manage everything from your Dashboard.
Content Management System – A software which helps to manage content a website.
cPanel – A web-based administration tool for managing your web hosting account.
Database – A software used to store and manage data in an orderly fashion.( i.e. MSQL )
Codex – The official WordPress manual with support articles, documentation, code snippets, and links to external resources.
Default theme – The theme that comes by default with a fresh installation of WordPress. Also used as a fallback theme if the current theme breaks.
DNS – Refers to the Domain Name System which maps domain names( like google.com) to its IP address.
Domain name – A system used to assign easy to remember names to IP addresses of websites.
DOM – An interface that allows programmers to dynamically access HTML and XML on a web page.
Footer area – The horizontal area at the bottom of the website where widgets and copyright information are usually displayed.
Header Image – A wide picture that can be set to appear at the top of your website.
Front end – The user-facing part of your website where visitors can view and interact with your content.
Gravatar – A service which lets users associate a global avatar (image or photo) with their email addresses.
Hosting provider – A company which sells space on a web hosting server for a fee.
IDE – An application which provides you with all the tools you need to develop and test software.
Menu – A collection of links to pages, categories, and social media profiles on your website usually displayed in the navigation area.
Meta – Can mean different things in WordPress depending on where it is used. Usually used to refer to administrative data.
Navigation – A set of links on your website which helps site visitors navigate through your content.
Nonce – A one-time token generated by WordPress to protect your site against unexpected or duplicate requests which can cause permanent or unintended consequences.
Multisite – Create a network of WordPress sites from a single WordPress installation.
Permalink – A permanent link to content on your website. Can be used to share unique pages on your website with others easily.
Sidebar – A place on your website where you usually display the search bar, recent and popular posts, and other important widgets. A website can have more than one sidebar.
XML-RPC – A remote procedure call (RPC) protocol which uses XML to encode its calls and HTTP as a transport mechanism.
Toolbar – The small black bar just above your site from where you can access quick links to various parts of your website. Usually visible only to logged in users.
Post – Also known as “articles” and sometimes incorrectly referred to as “blogs”. In WordPress, “posts” are articles that you write to populate your blog.
Post Slug – A few lowercase words separated by dashes, describing a post and usually derived from the post title to create a user-friendly (that is, readable and without confusing characters) permalink. Post slug substitutes the “%posttitle%” placeholder in a custom permalink structure. Post slug should not be changed and is especially useful if the post title tends to be long or changes frequently.
Post Type – Post type refers to the various structured data that is maintained in the WordPress posts table. Native (or built-in) registered post types are post, page, attachment, revision, and nav-menu-item. Custom post types are also supported in WordPress and can be defined with register_post_type(). Custom post types allow users to easily create and manage such things as portfolios, projects, video libraries, podcasts, quotes, chats, and whatever a user or developer can imagine.
Role – A role gives users permission to perform a group of tasks. When a user logs in and is authenticated, the user’s role determines which capabilities the user has, and each capability is permission to perform one or more types of task. All users with the same role normally have the same capabilities. For example, users who have the Author role usually have permission to edit their own posts, but not permission to edit other users’ posts. WordPress comes with six roles and over fifty capabilities in its role-based access system. Plugins can modify the system.
Screen – In WordPress a screen is a web page used for managing part of a weblog (site) or network. The term ‘screen’ is used to avoid confusion with ‘page‘, which has a specific and different meaning in WordPress. For example, the web page used to manage posts is known as the Posts Screen.
While the Internet makes up all communication between computers within any application, port, or protocol — the Web generally refers to networks of computers communicating over Hyper Text Transfer Protocol (HTTP), serving Hyper Text Markup Language (HTML) and related assets, such as images, stylesheets, and scripts.
All these technologies work together to create web sites and web applications, parsed by the web browsers and various Application Programming Interfaces (APIs).
When a user requests a web page in a web browser, the process typically looks like this:
Search, Social, or Direct Access: If a user types in a search phrase, and the browser bar also acts as a search bar, the web site of the default search engine is queried.
DNS Lookup: If the user types in an exact web address, or clicks a link from a social web site or search engine, a Domain Name Server lookup determines which computer should respond to the request.
Domain name servers can be overridden with a hosts file.
Some domain name servers can intercept, modify, and optimize content. For example, Cloudflare, which can add SSL, optimize HTML, optimize images, etc.
Connection & Headers: Browser negotiates either an insecure HTTP connection on default port 80, or a secure HTTPS connection on default port 443. Request headers and response headers are sent. These are viewable in the Web Inspector.
A web server doesn’t have to be running on default ports. For example, many development servers might load websites at localhost:8080 or any other arbitrary port.
Initial HTML & AJAX: If a browser request is the first request, HTML is most likely returned. This HTML usually contains references to hundreds of other files, which are requested and processed by the browser.
Initial HTML and AJAX requests, in our case, are typically handled by a Content Management System such as WordPress.
Each request spins up a new PHP process. One page might involve hundreds of HTTP requests!
Content Management Systems, such as WordPress, will typically not only spin up a programming language process, but also a database instance for content. This might be MySQL, SQLite, MongoDB (NoSQL), or many others.
If WordPress is not in use, PHP might still be in use with another PHP-based CMS such as Laravel.
If PHP is not in use, the web server could be using any number of server-side technologies, such as static assets (plain HTML or JavaScript), a NodeJS framework such as AdonisJS, or another language such as Ruby, Java, Python, or C# (Microsoft ASP.NET).
Static Assets: If the requested file is a static asset, such as CSS, JavaScript, or images, a PHP process is typically not spun up (though PHP can serve these things!) Instead, they are typically served directly by the web server (Apache, Nginx, a combination of these, or another server, such as Lighttpd or ASP.NET’s Kestrel server).
Serving static assets without PHP is faster than spinning up a PHP process — often by an order of magnitude.
Nginx is usually faster than Apache. For this reason, they are sometimes used together, with Nginx as a front-end proxy.
Static assets are sometimes offloaded to another server entirely — for example, a CDN such as Cloudflare CDN, Jetpack, or JSDelivr.
Each static asset, JavaScript, CSS, and images, require processing by the browser.
This processor utilization can be seen in the Web Inspector and browser metric tools such as Lighthouse.
For this reason, Lazy Loading (Jetpack) might be implemented for images, critical CSS might be inlined into the HTML head, and CSS or JavaScript may be minified or combined to optimize transfer speed and processing time.
Once a web page is loaded, the user starts to interact with the page. From here, simple web pages might link to other pages, re-initiating the entire cycle. If JavaScript is in use, as with Decoupled WordPress, ReactJS, or plugins like Flying Pages, JavaScript might be used to update page content without reloading initial HTML.
Caching: It’s important to note — caching may take effect at almost every step of the connection process. The browser has a cache. DNS may have a cache (Cloudflare), the CMS may have a cache, and there may be various application-level caches (WordPress wp_object_cache, WordPress Transients API, or plugins such as W3 Total Cache) or server-level caches, such as Redis, Varnish, or Nginx.
Resources
Whether you believe it or not, there are great resources out there that have helped hundreds of people with no technical background become web/WordPress developers. If you would like to explore this more for yourself, or just learn more about web development in general, here are some useful links: