In this series I will try to demonstrate best parts of WordPress from developers point.
Please visit https://developer.wordpress.org for full reference.
Got a bunch of users? Not a problem. WordPress lets you define different roles for different users – just like in real life – and lets you assign privileges accordingly. Users can register themselves (if you want), and can submit content for your review
WordPress is designed to be installed on your own web server, in the cloud, or in a shared hosting account.
You have complete control.
Unlike commercial software or third-party hosted services, you can be sure of being able to access and modify everything related to your site.
You can even install WordPress on your personal computer, or on a corporate intranet
Want to connect WordPress to another system? WordPress uses XML-RPC, an open XML standard that allows different systems in different environments to talk to one another. XML-RPC is designed to be as simple as possible, while at the same time allowing for complex tasks to be performed. WordPress also supports an extended version of the Blogger API, MetaWeblog API, and finally the MovableType API
WordPress can be extended to MultiSite feature on demand base. You are able to develop and maintain multiple sites using single WordPress installation. Multisite is a feature of WordPress 3.0 and later versions that allows multiple virtual sites to share a single WordPress installation. When the multisite feature is activated, the original WordPress site can be converted to support a network of sites
Out of the box WordPress comes with very robust tools such as an integrated blacklist and open proxy checker to manage and eliminate comment spam on your blog, and there is also a rich array of plugins that can take this functionality a step further
Though typically in the software world, a “major” version means you can break backwards compatibility, WordPress strives to never break backwards compatibility. Backwards compatibility is one of the project’s most important philosophies, with the aim of making updates much easier on users and developers alike
Automatic Background Updates for Security Releases
WordPress Security Team can identify, fix, and push out automated security enhancements for WordPress without the site owner needing to do anything on
their end, and the security update will install automatically
If there’s one cardinal rule in WordPress development, it’s this: Don’t touch WordPress core. This means that you don’t edit core WordPress files to add functionality to your site. This is because, when WordPress updates to a new version, it overwrites the local files. Any functionality you want to add should be added through plugins using approved WordPress APIs
There are two types of hooks within WordPress: actions and filters.
Actions allow you to add or change WordPress functionality,
Filters allow you to filter, or change, content as it is loaded
Did you know that WordPress provides a number of Application Programming Interfaces (APIs)? These APIs can greatly simplify the code you need to write in your plugins. You don’t want to reinvent the wheel—especially when so many people have done a lot of the work and testing for you. The most common one is the Options API, which makes it easy to store data in the database for your plugin. If you’re thinking of using cURL in your plugin, the HTTP API might be of interest to you. Since we’re talking about plugins, you’ll want to study the Plugin API. It has a variety of functions that will assist you in developing plugins.
Let’s talk a little bit about plugin development. I think this is one of the most important core feature of WordPress.
This is how you define plugin header:
Activation and deactivation hooks provide ways to perform actions when plugins are activated or deactivated.
Your plugin may need to do some clean-up when it is uninstalled from a site. A plugin is considered uninstalled if a user has deactivated the plugin, and then clicks the delete link.
When your plugin is uninstalled, you’ll want to clear out any rewrite rules added by the plugin, options and/or settings specific to to the plugin, or other database values that need to be removed. Less experienced developers sometimes make the mistake of using the deactivation hook for this purpose.
differences between deactivation and uninstall
When using uninstall.php, the plugin should always check for the WP_UNINSTALL_PLUGIN constant, before executing.
The WP_UNINSTALL_PLUGIN constant is defined by WordPress at runtime during a plugin uninstall, it will not be present if uninstall.php is requested directly. It will also not be present when using the uninstall hook technique.
WP_UNINSTALL_PLUGIN is only defined when an uninstall.php file is found in the plugin folder.
This is how it looks when you upload your plugin in your WordPress website. In this case dubebe-rss-importer the plugin I defined.
Here is an example removing database entries.