Summary: Understand the provided README.md files and WordPress Hooks Actions and Filters.
DEVELOPMENT.md
Post Types Order Plugin
This plugin is included in source code and will be useful for basic them development tasks.
All Git Branches
main branch is the root branch after every assignment is complete it will need to be merged into the main branch ( only if mentioned that it needs to be merged in DEVELOPMENT.md)
develop branch is the branch where over deployment code will go, when we want to see our code implemented on the provided sites we will have to merge main branch into develop.
feature/issue-name branches we will create for the assignment some assignment only have need one branch but others can need more branches.
fix/issue-name branch can be create to fix any errors or things in main branch.
Pull Request and issue notes
When we create a pull request (PR) the title should correspond to the issues it addresses. If the PR fixes a single issue ensure that the title is identical to the issue’s title and include the issue number at the beginning of the title. Such as GH-{issue number} {issue name} . In cases where the PR resolves multiple issues, the title should represent the overall category of the issues, like WordPress Development Basic Assignments or Basic Plugin Assignments. Along with the title we will have to make sure to provide a detailed description of the PR explaining what changes have been made and why. It’s also essential to assign a reviewer after finishing to the PR ensuring that it undergoes proper review.
For work-in-progress PRs instead of adding “WIP:” to the title we have to create a draft pull request which signals that the work is not yet complete. This will help in keeping the title clean and avoids confusion. Finally before the PR can be merged it must receive at least one approval from a reviewer confirming that the changes meet the required standards and are ready to be incorporated into the main codebase.
Third Party Plugin Workflow
To add third-party themes or plugins to our code base first create a new branch from the main branch. Once the new branch is ready add the third-party themes or plugins to it. After making these changes push the new branch to the repository and create a pull request (PR) against the main branch. In the PR description we have to include the [do-not-scan] label to prevent PHPCS from scanning the third-party themes or plugins.
After the PR has been reviewed and approved merge it into the main branch. Once the changes are in the main branch merge the main branch into the develop branch to keep it updated. Finally merge the main branch into any feature branch we have created to ensure consistency across all branches.
Workflow for WordPress Development Basics Course Tasks
Start by creating a feature/plugin branch from the main branch and push the new branch to the repository. While working on plugin assignment tasks continue to push your changes to the feature/plugin branch. Once we have completed all the plugin assignment tasks we have to raise a pull request (PR) against the main branch.
When raising the PR we have to make sure to follow the pull request and issue notes guidelines provided. After the PR is submitted a PHPCS scan will automatically run and provide feedback if there are any issues. We have to address any PHPCS feedback that arises and then request a code review.
If we are unsure who to request for the code review we have to reach out to the L&D team or our trainer for guidance. If the code reviewer requests changes we have to address the feedback in the same branch push the changes and re-request the code review. Once the pull request is approved we can proceed to merge it into the main branch.
Plugin Project Structure
├── plugin.php
└── inc
├── classes
│ └── class-plugin.php
│ └── <other_classes_maybe_in_subfolders>
├── helpers
│ └── autoloader.php
└── traits
└── trait-singleton.php
Namespaces
Namespaces are essential in our plugin to avoid naming conflicts and to logically organize our code. Each directory in our plugin structure can represent a different segment of the namespace allowing you to group related classes, traits, and functions together.
Singleton Trait
The trait-singleton.php file defines a Singleton trait that ensures a class can only have one instance throughout the application. This is useful for classes where having multiple instances could lead to conflicts or unnecessary resource usage.
plugin.php – The Entry Point
The plugin.php file is the main entry point for our plugin. It’s where we define essential constants like the plugin’s path and URL ensuring these values are easily accessible throughout our code. This file also includes our custom autoloader which dynamically loads the necessary classes as they are needed.
Custom Autoloader
Custom autoloader is defined in autoloader.php we be use used to automatically loads the required classes as they are needed based on the namespace and file structure.
Organizing Functionality
The plugin’s functionality can be organized in various ways. We can spread different functionalities, such as custom post types across multiple classes in dedicated folders. Alternatively we can register all functionalities within a single class if that suits our needs better.
SKELETON-GUIDE.md
|-- .github
| |-- hosts.yml
| `-- workflows
| |-- deploy_on_push.ym
| `-- phpcs_on_pull_request.yml
|
|-- .gitignore
|
|-- README.md
|-- SKELETON-GUIDE.md
|
|-- mu-plugins
| |-- plugin-update-notification.php
|
|-- phpcs.xml
|
|-- plugins
| `-- .gitkeep
|
|-- rt-config
| `-- rt-config.php
|
`-- themes
| `-- .gitkeep
|
|-- webroot-files
| `-- .gitkeep
The .github folder contains configurations and workflows related to GitHub actions, such as deployment and PHPCS checks. Since this folder is meant for CI/CD and other automated processes it should be ignored.
The .gitignore file lists the files and directories that should not be tracked by Git. This is important for keeping our repository clean.
The README.md file is guide for our project. It includes a checklist of best coding practices as well as links to development workflow and environment setup.
The phpcs.xml file defines the coding standards and rules that PHPCS (PHP CodeSniffer) will enforce. This ensures that all code written for the project adheres to a consistent style and quality making it easier to maintain and collaborate on.
The plugins directory is designated for plugin development. This is where all custom plugins will be created and maintained. It’s a dedicated space that keeps our plugin code organized and separate from other parts of the project.
The rt-config.php file functions similarly to wp-config.php but it is loaded afterward. This is where we can define custom constants and secrets specific to our project.
The themes directory is set aside for theme development. Like the plugins folder this provides organized space to develop and manage custom themes keeping them separate from other code.
README.md
Code Review Checklist
- Coding Standards and Best Practices: Ensure that all code adheres to the established coding standards and best practices.
- PHPCS Feedback: There should be no unresolved PHPCS feedback comments on our pull request (PR).
- Autoloader: Usage of Composer’s autoloader is discouraged for learning purposes. Instead we have to use a custom autoloader which will help us gain a better understanding of autoloading mechanics.
- Sanitization and Escaping: Properly apply sanitization and escaping throughout your code. For example ensure
esc_html()is not incorrectly used for escaping HTML tag attributes. - I18N Compliance: Make sure your plugin and theme are internationalization (I18N) ready. This means all static strings displayed to the user should be translatable using functions like
__()and the correct text-domain should be used. - Namespaces and Autoloading: Implement PHP namespaces and ensure that autoloading is properly configured to handle these namespaces.
- Object-Oriented Programming (OOP): We have to follow OOP principles in our code. This includes proper use of classes, inheritance, encapsulation, and other OOP concepts.
- Inline Documentation: Add inline documentation to our code. This will help others to understand our logic and the purpose of different code sections.
- PR Title and Description: Ensure that our PR titles and descriptions are descriptive and clearly communicate the purpose and scope of the changes.
Hooks in WordPress: Actions and Filters
In WordPress, hooks are a crucial feature that allow developers to modify or extend the core functionality without changing the core files. There are two main types of hooks: Actions and Filters.
Actions
Actions are hooks that allow you to add custom functionality or modify default behavior at specific points during the execution of a WordPress page. When an action hook is triggered, all the functions hooked to that action are executed in sequence.
This action hook to add custom content to the footer of a WordPress site:
// Function to add custom content to the footer
function my_custom_footer_content() {
echo '<p>Custom Footer Content</p>';
}
// Hooking the custom function to the wp_footer action
add_action('wp_footer', 'my_custom_footer_content');
wp_footer is an action hook that runs before the closing </body> tag in a WordPress theme. By hooking into wp_footer, the my_custom_footer_content function is executed, adding custom content to the footer.
Filters
Filters are hooks that allow you to modify data before it is displayed or processed. A filter hook passes data through a function, allowing you to alter it and return the modified data.
This filter hook to modify the text in the site title:
// Function to modify the site title
function my_custom_site_title($title) {
return 'My Custom Title | ' . $title;
}
// Hooking the custom function to the wp_title filter
add_filter('wp_title', 'my_custom_site_title');
wp_title is a filter hook that modifies the site title. the my_custom_site_title function appends custom text to the existing title. Whenever the title is displayed, it passes through this filter and is modified accordingly.
Combining Actions and Filters
We can use both actions and filters together to create more complex customizations. For example we can use an action to enqueue custom scripts and styles, while using a filter to alter the content being output on a page.
// Function to enqueue a custom script
function my_custom_enqueue_scripts() {
wp_enqueue_script('my-custom-js', get_template_directory_uri() . '/js/custom.js', array('jquery'), '1.0', true);
}
add_action('wp_enqueue_scripts', 'my_custom_enqueue_scripts');
// Function to modify the content of a post
function my_custom_content_filter($content) {
if (is_single()) {
$content .= '<p>Thank you for reading!</p>';
}
return $content;
}
add_filter('the_content', 'my_custom_content_filter');
my_custom_enqueue_scripts is hooked to wp_enqueue_scripts to load a custom JavaScript file. Simultaneously, my_custom_content_filter modifies the content of a single post to append a thank you message.
Leave a Reply