Fix typos

Add WordPress section to main page

index.md

@@ -13,7 +13,7 @@ Engineering and Tech are complex ; there are many possible ways of working, appr
 
 There is so much to know to craft software that having a reference can greatly help to address questions such as "How should we do this?", "Has anyone experienced this before?". This handbook should be a go-to for any engineering teammate facing those questions and looking for already-experienced solutions within the company.
 
-This is an ever on-going process as we constantly learn, deconstruct, reinvent and revisit: this handbook should be the reflect of this learning process and help to capture the *what* and the *why*. This way, every best practice can be self-standing and eventually challenged to keep on refining.  Every document of this handbook describes the best way someone previously found to address the issues they encountered: maybe the issues and context changed since then, maybe they missed a better approach, etc. We are doing our best, and you can do it too by challenging and contributing.
+This is an ever ongoing process as we constantly learn, deconstruct, reinvent and revisit: this handbook should be the reflection of this learning process and help to capture the *what* and the *why*. Hence, every best practice can be self-standing and eventually challenged to keep on refining.  Every document of this handbook describes the best way someone previously found to address the issues they encountered: maybe the issues and context changed since then, maybe they missed a better approach, etc. We are doing our best, and you can do it too by challenging and contributing.
 
 As part of the WordPress ecosystem, WP Media believes in open source and actively contribute to open-source projects. Therefore, it is important for us to publicly maintain our Engineering handbook to provide transparency about our engineering practices, foster standardization, best practices and quality in the industry, share knowledge and finally open the dialogue on the topic.
 
@@ -23,7 +23,7 @@ This handbook is primarily designed by and for WP Media Engineering teammates to
 
 Therefore, it does not aim at teaching anyone how to be or become an engineer. 
 
-While this handbook may containing valuable take-aways for other engineers, it is opinionated and does not try to reflect the perfect state-of-the-art of engineering.
+While this handbook may contain valuable takeaways for other engineers, it is opinionated and does not try to reflect the perfect state-of-the-art of engineering.
 
 ### Contributing
 
@@ -37,4 +37,5 @@ This handbook is maintained by WP Media Engineering team. The website is built f
 #### [Processes](ways_of_working/processes/index.md)
 #####  [Reviews](ways_of_working/processes/reviews.md)
 ### [Technical standards](technical_standards/index.md)
-#### [PHP](technical_standards/php/index.md)
+#### [PHP](technical_standards/php/index.md)
+##### [WordPress](technical_standards/php/wordpress/index.md)

technical_standards/php/wordpress/filters.md

@@ -7,28 +7,28 @@ title: WordPress Filters - Best practices
 
 Filters are one of the two types of Hooks provided by WordPress as a way for third-parties to modify data dynamically during execution of the code. Read [the official documentation](https://developer.wordpress.org/plugins/hooks/filters/) for more details.
 
-Filters are a pwoerful feature of WordPress that we extensively use within our plugins to make them customizable easily.
+Filters are a powerful feature of WordPress that we extensively use within our plugins to make them customizable easily.
 
 ## PHP Types and filters
 ### The issue with filters loose typing
 
-WordPress filters have no typing check in place. This means that it’s not possible to trust the returned value of a filter, because anyone could have modified it using the filter and returned an unexpected type. 
+WordPress' filters have no typing check in place. This means that it’s not possible to trust the returned value of a filter, because anyone could have modified it using the filter and returned an unexpected type. 
 
 In consequence, this can cause errors with the code using this value, especially if it expects a specific type, for example a method with typed parameters. 
 
-Our plugins are used by thousands of users, on millions of websites so we must expect that someone will mess with our filters at some point. Moreover, the error will usually be reported from a file within our plugin's codebase, even if the mistyped value is introduced by another third-party.
+Our plugins are used by thousands of users, on millions of websites, so we must expect that someone will mess with our filters at some point. Moreover, the error will usually be reported from a file within our plugin's codebase, even if the mistyped value is introduced by another third-party.
 
 ### Safeguarding returned value
-To prevent this issue, whenever we implement a custom filter in our code, we need to safeguard the returned filter value before using it further: in case the filtered value is not as expected, we should fallback to the default one. 
+To prevent this issue, whenever we implement a custom filter in our code, we need to safeguard the returned filter value before using it further: in case the filtered value is not as expected, we should fall back to the default one. 
 
-The safeguarding mechanism is usually based on types, but can be stricter depending on the context: for instance, a price must be a float but also be stricly positive.
+The safeguarding mechanism is usually based on types, but can be stricter depending on the context: for instance, a price must be a float but also be strictly positive.
 
 Our current approach to this is to use the [apply-filters-typed library](https://github.com/wp-media/apply-filters-typed). It has the benefit of adding logs in debug mode to warn developers of filters being misused. Complex value checks can be handled with [the custom type validation feature](https://github.com/wp-media/apply-filters-typed?tab=readme-ov-file#create-your-own-type-validation) of the library.
 
 Note that the same approach applies to callbacks re-using the argument being filtered.
 
 #### Previous practice
-Before the introduction of this library, or when complex validation is needed, we were explicitely validating the returned value as follows:
+Before the introduction of this library, or when complex validation is needed, we were explicitly validating the returned value as follows:
 ```php
 // Variable with the default value for the filter
 $default = 10;
@@ -44,7 +44,7 @@ if ( ! is_int( $value ) ) {
 In addition to checking for type, we could also test against the value, for example in the case where we expect it to be a positive integer only. All those cases should now be handled with [apply-filters-typed library](https://github.com/wp-media/apply-filters-typed). When reworked, code using the old approach can be rewritten to leverage our new standard.
 
 ### Automated tests of filters
-To validate the safeguarding of the filtered value, it is recommended adding a serie of fixtures while writing unit/integration tests for the method using it.
+To validate the safeguarding of the filtered value, it is recommended adding some fixtures while writing unit/integration tests for the method using it.
 
 The fixtures can pass different values to the filter and validate against the expected output. The following list of values can be used:
 

ways_of_working/processes/reviews.md

@@ -9,7 +9,7 @@ title: Pull Requests & Code Reviews
 
 Crafting software is complex, and as good as they can be, developers are human beings: they can make mistakes, miss something, or simply not think about the best approach right away.
 
-We are working in teams, where several developers will successively work on the same code. To ease this collaboration, we need to standardize our code style, the code quality and expectations: moving from one codebase to another must be as seemless as possible, and anyone should be able to pick up anyone else code seemlessly.
+We are working in teams, where several developers will successively work on the same code. To ease this collaboration, we need to standardize our code style, the code quality and expectations: moving from one codebase to another must be as seamless as possible, and anyone should be able to pick up anyone else code seamlessly.
 
 Finally, reviews are a great way to share knowledge, continuously learn and improve yourself and your team.
 
@@ -31,7 +31,7 @@ If your PR covers a complete fix/enhancement/feature on its own, then the target
 
 ### Pull Request description
 
-The Pull Request description is the document that will follow your code until it reaches production, through peer reviews, QA testing, release notes and documentation. For all teammates to perform those steps accurately, they need to quickly grasp the context of your PR, the reasons why the implementation has been done this way, what it changes, etc. While this is obvious for you after spending hours working on it, it is likely not the case for teammates ; so make sure to make the Pull Request as self-standing as possible!
+The Pull Request description is the document that will follow your code until it reaches production, through peer reviews, QA testing, release notes and documentation. For all teammates to perform those steps accurately, they need to quickly grasp the context of your PR, the reasons why the implementation has been done this way, what it changes, etc. While this is obvious to you after spending hours working on it, it is likely not the case for teammates ; so make sure to make the Pull Request as self-standing as possible!
 
 To achieve this, a default Pull Request template is automatically applied on new Pull Requests of WP Media owned repositories on GitHub. This template is maintained [here](https://github.com/wp-media/.github/blob/main/.github/PULL_REQUEST_TEMPLATE.md). Specific templates can override this generic one in some specific repositories.
 
@@ -43,7 +43,7 @@ As the PR owner (creator), you are responsible for getting reviews once the PR i
 
 Many things happen every day within our teams: it is easy to miss an opened PR. To make sure your PR get reviews check that it is visible as "Ready for Review" on your team's board, in the current sprint. Also assign the team tag as reviewer, so that teammates are notified.
 
-Our teams SLA is to handle reviews within 24 hours. If you don't get any reviews after 24 hours, kindly ask for one on Slack specifying what the PR is about and consider pinging relevant teammates. You should also leverage the daily standup meeting to find reviewers.
+Our teams SLA is to handle reviews within 24 hours. If you don't get any reviews after 24 hours, kindly ask for one on Slack specifying what the PR is about and consider pinging relevant teammates. You should also leverage the daily stand-up meeting to find reviewers.
 
 ## CI - Automated Continuous Integration Pipeline
 
@@ -53,11 +53,11 @@ On GitHub, we leverage GitHub actions to implement our CIs.
 
 ### Pull Request Description validation
 
-The importance of the Pull Request description is emphasised above in this document. We have [an automated check](https://github.com/wp-media/pr-checklist-action) that ensures the standardized PR template is properly filled. This check can help quickly identify Pull Requests not up to standards so that the owner can fix it, and avoid reviewers to begin reviewing while some context is missing.
+The importance of the Pull Request description is emphasized above in this document. We have [an automated check](https://github.com/wp-media/pr-checklist-action) that ensures the standardized PR template is properly filled. This check can help quickly identify Pull Requests not up to standards so that the owner can fix it, and avoid reviewers to begin reviewing while some context is missing.
 
 ### Linting, Code Style and Code Standards
 
-Developers have to work on many repositories. To minize cost of context switching and feel at home in every codebase, it is important to share common style guidelines. Also, keeping code easy and natural to read is key for efficiency in the long run.
+Developers have to work on many repositories. To minimize cost of context switching and feel at home in every codebase, it is important to share common style guidelines. Also, keeping code easy and natural to read is key for efficiency in the long run.
 
 All our CI must include steps and tools to:
 - Check code style. This ensures conventions and rules about formatting and code structure are applied (indentation, naming conventions, spacing, etc.)
@@ -70,10 +70,10 @@ For each language that we use, we leverage different tools. Refer to the section
 
 Automated tests are a key asset of our codebases. They are designed to capture some behaviors of the codebase and check that they can consistently be reproduced across evolutions of the software.
 
-Everytime we alter the code (hence, for every PR), we must ensure that those behaviors are still reproducible. So all tests must run and pass as part of the CI.
+Every time we alter the code (hence, for every PR), we must ensure that those behaviors are still reproducible. So all tests must run and pass as part of the CI.
 
 If tests are not passing, it means a behavior changed:
-- if this is expected as a result of the code change, the tests must be adapted to reflect this change.
+- if this is expected as a result of the code change, the tests must be adapted to reflect this change;
 - if this is not expected, then a regression has been introduced and the code change must be reviewed to fix the issue.
 
 For each language that we use, we leverage different tools. Refer to the section of each language for more details and examples.
@@ -82,8 +82,8 @@ For each language that we use, we leverage different tools. Refer to the section
 
 To ensure that the changes we introduce will be stable over time and prevent them to be impacted by regressions, it is critical to cover those changes with automated tests. Adding tests to capture the behaviors we introduce is a great way to demonstrate how the code should behave, and to allow future maintainers to easily check they did not alter this expected behavior.
 
-Diff coverage step identifies all lines being modified by your PR, and checks wheter or not they are executed during test execution. This approach allows to only focus on what the current PR is changing, regardless of the overall coverage level of the repository.
+Diff coverage step identifies all lines being modified by your PR, and checks whether they are executed during test execution. This approach allows to only focus on what the current PR is changing, regardless of the overall coverage level of the repository.
 
-When a line is not covered, it means that it could be removed or alteredwithout any tests failing, which is a great risk for regression in the future.On the contrary, a covered line is not totally safe: a line being executedduring a test does not mean its logic is fully tested and validated. Therefore,diff coverage must be taken as an indication of untested lines of code fordevelopers to self-review and improve autonomously their coverage.
+When a line is not covered, it means that it could be removed or altered without any tests failing, which is a great risk for regression in the future. On the contrary, a covered line is not totally safe: a line being executed during a test does not mean its logic is fully tested and validated. Therefore, diff coverage must be taken as an indication of untested lines of code for developers to self-review and improve autonomously their coverage.
 
 We globally aim at a minimum of 50% diff coverage. Below this, this step of the pipeline must fail.

ways_of_working/team/missions_and_purposes_of_the_engineering_team.md

@@ -11,21 +11,21 @@ The Engineering team designs, implements, delivers and maintains production-read
 
 ### Missions & Responsibilities:
 
-- Implements and delivers features into our products to match the product & marketing teams’s vision ;
+- Implements and delivers features into our products to match the product & marketing teams' vision ;
 - Monitor and maintain the quality of our products and services to ensure a best-in-class quality of service ;
 - Assist the support team to investigate issues and provide solutions so that our customers can fully benefit from our products ;
 - Continuously explore, contribute and improve engineering practices and throughout WP Media, group.One and the WordPress community to foster a culture of technical innovation and excellence.
 
 ## Service team
 
-The Engineering Service team implements and maintains WP Media’ services for internal and external users so that the company can efficiently delivers the best web optimization experience.
+The Engineering Service team implements and maintains WP Media’ services for internal and external users so that the company can efficiently deliver the best web optimization experience.
 
 ### Missions & Responsibilities:
 
-- Monitor, maintain and improve commercial services (company’s websites, order & license system) to implement the product & marketing teams’s vision ;
-- Monitor, maintain and improve optimization services (product services) to implement the product & marketing teams’s vision ;
+- Monitor, maintain and improve commercial services (company’s websites, order & license system) to implement the product & marketing teams' vision ;
+- Monitor, maintain and improve optimization services (product services) to implement the product & marketing teams' vision ;
 - Monitor, maintain and improve back-office services, tooling and architecture (data, technical stacks, tooling, monitoring & alerting, infrastructure) to achieve the best-in-class quality of service and empower WP Media’s teams ;
-- Leverage synergies with group.One infrastructures and teams for our back-end services to continuously improve the team’s efficiency.
+- Leverage synergies with group.One's infrastructures and teams for our back-end services to continuously improve the team’s efficiency.
 
 ## Plugin team