Build lobby based online multiplayer browser games with React and NodeJS

Introducing Stripe payment into your PHP projects

For most of WordPress projects, we need to load posts, that’s why I’d like to share with you a useful class to handle this.

## Without a post loader

I’m pretty sure you came across code like this through your WordPress projects :

```php
$query = new WP_Query([
    'post_type' => 'custom_post_type_name',
    'order' => 'ASC',
    'posts_per_page' => 5,
]);
$posts = $query->get_posts();
 
/** making stuff with these posts... */
```

It’s basically the most standard way of retrieving posts, it’s efficient and convenient most of the time.

Now, to spice things a bit, I would like to paginate the results of this query.
So first I’ll have to check if any parameter is set (like page in the url, or directly the `get_query_var('page')` available from WordPress) and then if it’s the case, then I’ll to edit query’s arguments.
I would also like to retrieve my posts by years, then I’ll need another condition and edit query’s arguments…

Well, let’s see how it looks :
```php
$args = [
    'post_type' => 'custom_post_type_name',
    'order' => 'ASC',
    'posts_per_page' => 5,
];
 
if (!empty($_GET['yr'])) {
    $year = (int) $_GET['yr'];
    $args['date_query'] = [[
        'year' => $year,
    ]];
}
 
$currentPage = (int)(get_query_var('page')) ? get_query_var('page') : 1;
 
$args['paged'] = $currentPage;
 
$query = new WP_Query($args);
$posts = $query->get_posts();
 
/** making stuff with these posts... */
```

If this kind of stuff happens in your templates or functions then this will getting out of hand pretty quickly if it needs more customization like adding ACF argument aswell, or any kind of maintenance (by you or others developers).
Also, note that we didn’t even render pagination based on the query results...

Also, if you need to repeat queries like this then it’s even more difficult to maintain through your whole project.

That’s why I’d like to share a very minimalist class to handle these kind of operations.

## With a post loader

First, let’s see how we use it :
```php
<?php
use App\PostLoader;
 
$loader = new PostLoader('custom_post_type_name', get_permalink(get_the_ID()), 5);
$posts = $loader->getPosts();
 
/** making stuff with these posts... */
```

This example is the same as the first, you retrieve the same posts based on the parameters you gave to the constructor.

Let’s see now how to add arguments to our loader :
```php
$loader = new PostLoader('custom_post_type_name', get_permalink(get_the_ID()), 5);
 
if (!empty($_GET['yr'])) {
    $loader->setArgument('date_query', [[
        'year' => (int)$_GET['yr'],
    ]]);
}
 
$posts = $loader->getPosts();
```

We can retrieve every post of the year specified, another benefit that this class offer is the rendering of the pagination, simply call it like this :
```php
echo $loader->getPagination();
```

Which builds for you all the html needed for pagination.
You also need to inject some parameters in the pagination links ? You can render pagination like this aswell :
```php
echo $loader->getPagination(['yr' => (int)$_GET['yr']]);
```

So when you go through pages, you won’t lose any parameters already set.

## PostLoader class

Here’s the class:
```php
<?php

namespace App;
 
use WP_Query;
 
class PostLoader
{
    /** @var string */
    private $postType;
    
    /** @var string */
    private $basePageUrl;
    
    /** @var int */
    private $postsPerPage;
    
    /** @var int */
    private $page;
    
    /** @var int */
    private $totalPosts;
    
    /** @var int */
    private $totalPages;
    
    /** @var array */
    private $params;
    
    /**
     * @param string $postType Post type to retrieve
     * @param string $basePageUrl Url of the page that handles your posts archives
     * @param int $postsPerPage How many posts to retrieve per page
     */
    public function __construct(string $postType, string $basePageUrl, int $postsPerPage)
    {
        $this->postType = $postType;
        $this->basePageUrl = $basePageUrl;
        $this->postsPerPage = $postsPerPage;
        $this->params = [
            'post_type' => $this->postType,
            'posts_per_page' => $this->postsPerPage,
        ];
    }
    
    /**
     * @param int|null $page Specify which page to retrieve if needed, fallback to "page" query var
     * 
     * @return array
     */
    public function getPosts(?int $page = null): array
    {
        if ($page === null) {
            $this->page = (int)(get_query_var('page')) ? get_query_var('page') : 1;
        } else {
            $this->page = $page;
        }
        
        $this->setArgument('paged', $this->page);
 
        $query = new WP_Query($this->getParams());
 
        $this->totalPosts = (int)$query->found_posts;
        $this->totalPages = (int)$query->max_num_pages;
 
        return $query->get_posts();
    }
    
    /**
     * @param array|null $params If parameters needs to be injected inside the link
     * 
     * @return string
     */
    public function getPagination(?array $params = null): string
    {
        $paramsString = '';
 
        if (!empty($params)) {
            $paramsString = '?' . http_build_query($params);
        }
 
        $html = '<ul class="paginationContainer">';
 
        // If we haven't already call the getPosts method then we do it now
        if ($this->totalPages === null) $this->getPosts();
 
        for ($i = 1; $i <= $this->totalPages; $i++) {
            $addedClasses = '';
 
            if ($i === $this->page) {
                $addedClasses .= ' activeItem';
            }
 
            $html .= "
                <li class='paginationItem {$addedClasses}'>
                    <a href='{$this->basePageUrl}{$i}{$paramsString}' class='paginationLink'>{$i}</a>
                </li>
            ";
        }
 
        $html .= '</ul>';
 
        return $html;
    }
    
    /**
     * @param string $key Argument key
     * @param mixed $value Argument value
     * 
     * @return self
     */
    public function setArgument(string $key, $value): self
    {
        $this->params[$key] = $value;
 
        return $this;
    }
    
    /**
     * @return array
     */
    public function getParams(): array
    {
        return $this->params;
    }
}
```

It really aims to stay simple and to evolve or extend depending on project.
As you can see, you can easily edit how pagination is built (you could even use a view if needed), change how things are implemented and add your own logic.

Using an object-oriented approach allow us to easily edit the behaviour of the loader but also add new to it. (with other benefits like being reusable, easier to test, cleaner...)

Aswell, you can note that we can override the page being called with the `getPosts()` method, this is quite useful when you doing [ajax loading](/articles/wordpress-ajax-an-object-oriented-way) and you need to call a precise page through your request. (otherwise it fallback to `get_query_var('page')` if set or first page )

Queries being handled directly from this post loader, this lighten your templates (or functions) and allow you to have a constant and easier api to work with.
(it also encourages you to work with objects ! :D)

I hope you’ll see some uses for this tiny code, it’s totally free to use ! :)

Thanks for reading !

WordPress - A minimalist post loader

Today I’d like to share with you a more object oriented way to handle ajax within WordPress.

## "Classic" Way

I’ve been doing a lot of ajax with WordPress, I’ve done it the “original” way where you put the code in your `functions.php` and it would look like this :
```php
<?php
function add_js_scripts() {
    wp_enqueue_script('script', get_stylesheet_directory_uri().'/js/script.js', array('jquery'), '1.0', true);

    // pass Ajax Url to script.js
    wp_localize_script('script', 'ajaxurl', admin_url('admin-ajax.php'));
}
add_action('wp_enqueue_scripts', 'add_js_scripts');

add_action('wp_ajax_my_action', 'my_action');
add_action('wp_ajax_nopriv_my_action', 'my_action');

function my_action() {
    $param = $_POST['param'];
    echo $param;
    die();
}
```

And then you would put your jQuery ajax this way :
```js
$.ajax({
    url: ajaxurl,
    method: 'POST',
    data: {
        action: 'my_action',
        username: 'Frast',
    },
    success: function (response) {
        console.log(response);
    },
});
```

This approach always worked (and always will, I guess), but we can spot few drawbacks using procedural way, like :
* It's polluting the `functions.php`, what happens when you’ll get 2, 5, 15 ajax actions ? (To avoid this, I’ve always split my actions into different files to stay organized)
* You’ll have to edit a lot of text (function name, your javascript file name maybe, your actions name, ...) in the case scenario where you need to edit your action name
* You’ll repeat a lot of the same code most of the time
* You’ll maybe wrap your code into some conditions if you want to load it only in certains scenarios
* If you have more than one action and so you call `wp_localize_script()` more than once, it just duplicate code, which is not very useful (in ajax case, you’ll always need to bind it to `admin-ajax.php`)
* …

## Going OOP
To simplify all of this, I’ve made a **small** package that you can install with composer :
```
composer require frast/wp-aoo
```
*(It’s about 2 files to be honest)*

Once installed, you can go to your `functions.php` and require your composer autoload like this :
```php
require(__DIR__ . '/vendor/autoload.php');
```

For the next part, I’ll make the assumption that you created a `src/` folder in your theme and inside it you’ll make the class `MyAction` inside another `Ajax/` folder.  
Also, for organization sake, you’ll make another file called `loadAjax.php` in the `src/` folder and require it from the `functions.php` (after the autoload require).  
Finally, you’ll create the js file linked to the ajax action, we’ll call it `MyAction.js`

Your theme directory should look like this:
```
- assets/
    - js/
        - MyAction.js
- src/
    - Ajax/
        - MyAction.php
    - loadAjax.php
- vendor/
    - frast/
    - autoload.php
- functions.php
```

Inside your class `MyAction` the most basic code could be :
```php
<?php
# src/Ajax/MyAction.php

namespace App\Ajax;

use Frast\AjaxHandler;

class MyAction extends AjaxHandler
{
	/** @var array I specify that my js script will need jQuery as a dependency */
	protected $dependencies = [
		'jquery',
	];

	/**
	 * Return the path of the javascript file binded to the action
	 */
	public function getAssetSrc(): string
	{
		return get_stylesheet_directory_uri() . '/assets/js/MyAction.js';
	}

	/**
	 * How the action is going to handle the requests
	 */
	public function treatment(): void
	{
		// Do your stuff here, don't forget to sanitize user inputs in real case scenario
		$username = $_POST['username'];

		// JSON Response sent back
		wp_send_json([
			'message' => "Hello {$username} !",
		], 200);
	}
}
```

Inside `MyAction.js` :
```js
// assets/js/MyAction.js

jQuery(document).ready(function () {
	// console.log(WP_ADMIN_AJAX);
	// console.log(MyActionNonce);

	jQuery.ajax({
		url: WP_ADMIN_AJAX, // This is globally available, it resolves to the admin ajax url
		method: 'POST',
		data: {
			// The action must be the same as the name of your php class
			action: 'MyAction',
			// For security reason, you must specify the nonce created for your php class
			// You can get it by suffixing "Nonce" to your php class, like so
			nonce: MyActionNonce,
			// Then send whatever data you like
			username: 'Stranger',
		},
		success: function (response) {
			console.log(response);
		},
	});
});
```

And finally to load your `MyAction` handler, put this in your `loadAjax.php` :
```php
<?php
# src/loadAjax.php

use Frast\AjaxLoader;
use App\Ajax\MyAction;

// We register our ajax handlers
(new AjaxLoader())
	->register(MyAction::class)
	->load()
;
```

You can try it as is, it should work ! (hopefully :p)  
By the way, don't forget to autoload your `App` namespace (from `src/`) in your `composer.json`, like so :
```
{
    "require": {
        "frast/wp-aoo": "^1.0"
    },
    "autoload": {
        "psr-4": {
            "App\\": "src/"
        }
    }
}
```
And then to refresh the autoload with the command `composer dump-autoload`  
You can find a full demo of the package [here](https://github.com/Mazzzoni/demo-wp-aoo)

## How it works

The class `MyAction` declared two methods :
* `getAssetSrc()` : It returns the path of the js file that the action is binded to
* `treatment()` : It treats the request made on this action

Where you would normally put `wp_ajax_nopriv_my_action` and `wp_ajax_my_action`, `MyAction` inheriting from `Frast\AjaxHandler` will automatically do it for you based on the class name.  
It will also call `wp_enqueue_script()` with the arguments that you defined. (see customization below)

After that we register our class within `loadAjax.php` with :
```php
(new AjaxLoader())
    ->register(MyAction::class)
    ->load()
;
```

This simply register all of the handlers we want and then load them for WordPress to use them. (which will call the `add_action()` and `wp_enqueue_script()` with the config you gave to each handler)

[All the code is available here and is free to use for literally anything](https://github.com/Mazzzoni/wp-aoo)

This is quite a small library so it would’nt be too long to grasp how it works.

## Why would I use this ?

By using this approach you get :
* A clean way to organize your files
* Most of the time files will stay pretty small, but if it grows, your logic will remains inside a well defined class (but keep in mind to stay a bit **SOLID**)
* If another developer have to catch up with your code, he can instantly see what you’ve loaded, which js file you’re querying, …
* You can define concise conditions for loading (see customization below)
* You can define clearly dependencies, version and in_footer if needed
* You could automate even more things, like how the binded javascript file is fetch by extending the `AjaxHandler` class and specify an ajax javascript folder and then automatically fetch a javascript file that has the same name as your php class. That is an example of how you could easily take profit from doing OOP way
* ...

It also encourages you to go a bit more object oriented inside WordPress development since a lot of tutorials and way of doing are more procedural-like.

## Customization

Sometimes, you would like to load an handler only if certains conditions are met.  
You can do that by declaring this in your handler class :
```php
/**
 * Based on the return value, it will enable or not the ajax action
 */
public function conditions(): bool
{
	// You can also access WordPress functions from here
	$canLoad = is_home();

	return $canLoad;
}
```

Based on the return value, it will load or not your handler, saving some computation time and a browser request. (since it won’t `wp_enqueue_script()` your js script)

Also, since you can specify optionnals arguments to `wp_enqueue_script()`, you can redefine them with :
```php
/** @var array */
protected $dependencies = [];

/** @var string|bool|null */
protected $version = false;

/** @var bool */
protected $inFooter = true;
```

Inside your handler class.

You can basically override anything from your handler class if needed.

## Conclusion

This package can help you to better organize your files and logic on larger project (even if I use it on small project aswell) and this is quite valuable when you have to maintain projects !

I've also made a demo project that is available [here](https://github.com/Mazzzoni/demo-wp-aoo) which contains few examples of how you can profit from this package.

I hope that you can find any utility to this **quite small** package and aswell that it will motivates you to go a bit more into OOP if it's not already the case ! :)

WordPress Ajax - An object oriented way

Quite often I read threads on [/r/php](https://www.reddit.com/r/PHP) and sometimes I see people that share their custom PHP framework, a bit curious, I read the thread and analyze the linked repository, most of the time the framework has some small (or big) flaws.

If you have in mind creating a framework (PHP or another language, we'll talk PHP here) or if you already have a framework and you wish to make it better and to maintain it, I'd like to give you some advices.

## PHP Standards Recommendations

The *PSR* ([PHP Standards Recommendations](https://www.php-fig.org/psr/)) are conventions adopted and followed by "most" of the developers. They are designed to standardize code and to make the [interoperability](https://en.wikipedia.org/wiki/Interoperability) between system better.

The PSR system allows to suggest new convention and then the members of the community agree or not to it.

For example, by following the [PSR-2 "Coding Style Guide"](https://www.php-fig.org/psr/psr-2/) your code **must** follow a certain style, here are some rules ;
* Use 4 spaces for indenting instead of tabulation
* Put a space after the declaration of namespace
* Method's brackets must be on their own line (so not on the end of current line)

Here is a piece of code *(took from the official website)* which is PSR-2 compliant :
```php
<?php

namespace Vendor\Package;

use FooInterface;
use BarClass as Bar;
use OtherVendor\OtherPackage\BazClass;

class Foo extends Bar implements FooInterface
{
    public function sampleMethod($a, $b = null)
    {
        if ($a === $b) {
            bar();
        } elseif ($a > $b) {
            $foo->bar($arg1);
        } else {
            BazClass::bar($arg2, $arg3);
        }
    }

    final public static function bar()
    {
        // method body
    }
}
```

If you make an open-source framework and so designed for a large public, it is strongly recommended to follow this convention because it will make your code more familiar to other developers but also making you feel more familiarised with other's code.  
You don't have to follow strictly every PSR but if you do, there is more chances that other developers won't be lost. (and if you don't follow it, please stay constant in your codebase)

## Namespaces

Namespaces allow you to better organize your code. Instead of giving you an abstract definition, here are some code to explain how they are useful.

```php
<?php

namespace App\Controller;

use Framework\Controller\AbstractController;
use Framework\Http\Response;

final class HomeController extends AbstractController
{
    public function index(): Response
    {
        return new Response('Hello World!');
    }
}
```

With the following code, we can see :
* The class `HomeController` has been declared in the namespace `App\Controller` (on the third line)
* We use `AbstractController` from the namespace `Framework\Controller`
* We use `Response` from the namespace `Framework\Http`

What if we reproduce the code **without** namespaces ?

```php
<?php

require('./../../Framework/Controller/AbstractController.php');
require('./../../Framework/Http/Response.php');

final class HomeController extends AbstractController
{
    public function index(): Response
    {
        return new Response('Hello World!');
    }
}
```

It would work, isn't it ?

Now, what happens if in the file `AbstractController.php` the class `HomeController` has already been declared ? The code breaks simply.  
Well, we can prefix every class of our project with `App` or `MyFrameworkName` but we'll never be sure that a class hasn't been declared already...

Now what happens if the framework user change a file in another directory to refactor ? He has to change every path of his requires...

What happens if in `AbstractController.php` and `Response.php` the same dependency is declared ? We would use `require_once()` everywhere and lose some performances ? We wrap every class in `class_exists()` ?

Namespaces allow a lot of things, mostly to avoid **the collision between classes name** but also to organize your files by thematics / scopes so you can get a well structured codebase.

Finally, namespaces work well with autoloading, if you are [PSR-4: Autoloader](https://www.php-fig.org/psr/psr-4/) compliant.

## Composer

[Composer](https://getcomposer.org/) is a dependency manager, it allows you to easily get, maintain and manage your project dependencies in a few command lines.

It also has the serious benefit to manage your namespaces. It can manage them with it's autoloader and also manage your dependecies namespaces (e.g. : doctrine, monolog, swiftmailer, ...)

We could say that if you don't use Composer you'll have a hard time to handle your files inclusions and to maintain your codebase.

## Performances

Even if PHP 7 gained a lot in performances, if you decide to make a framework, it has to be performant too to be appealing to potential users.

So, in your codebase things like this, should **not** exist :
```php
for ($i = 0; $i <= count($myArray); $i++) {
    // ...
}
```
*This example is probably the most known*

This loop is slower than if we assigned `count($myArray)` to a variable and then execute the for loop.  
It is caused by every iteration of the loop, PHP ask which length is `$myArray`.  
On small arrays, this shouldn't be felt but on bigger arrays it can cause some slowness in your application. That said, think about your code that is going to be used by numerous people, you don't know how exactly they'll use it so it's always good to save a few ms.

The *"good"* way of doing it would be :
```php
$myArrayLength = count($myArray);
for ($i = 0; $i <= $myArrayLength; $i++) {
    // ...
}
```

or even :

```php
for ($i = 0, $j = count($myArray); $i <= $j; $i++) {
    // ...
}
```

## SOLID Principles

[SOLID Principles](https://stackify.com/solid-design-principles/) define some basics for object oriented code. They allow to specify a directive line of development in your project to make it more robust and maintainable.

By following these principles, you more likely to avoid what we call **"spaghetti code"** by defining your classes with a specific goal. (**Single Responsability Principle**)

Your framework users (or yourself) to manipulate classes without breaking everything. (**Open/Closed Principle**)

In a more global perspective, it makes your code more maintainable, understable and easier to evolute.

You can also look at other principles like [KISS](https://en.wikipedia.org/wiki/KISS_principle), [YAGNI](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) and [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) which can also help you in your development.


## Documentation

Documentation is a significant part of every project, without documentation it can be quite complicated for you to maintain your framework, but most importantly, for your users to understand your tool and so to use it.

```php
<?php

namespace Framework\Controller;

use Framework\Controller\AbstractController;
use Framework\Http\Response;

final class HomeController extends AbstractController;
{
    public function index(): Response
    {
        return new Response('Hello World!', 200, []);
    }
}
```

Without documentation how to know how work the class `AbstractController` ? What arguments takes `Response` ?

Think about writing a clear and concise documentation, it also helps your users if you give concrete example of how your tool works.  
Also, documentation **should be written in parallel** of development, don't let rot your documentation.

## Unit tests

Unit tests are probably the most missed in every homemade framework I saw on reddit.  
Still, it's probably the most important piece that your framework must have...

Unit tests gives you a lot of benefits like ; you can check your code quality to see if it isn't decreasing, without tests, how would you know if your new functionality hasn't broke another piece of code that you wouldn't even think about ?

Units tests allows you to make your development more **agile**, if tomorrow your community asks for a refactor on your way of dealing with database (which is quite crucial in an application), units tests makes you feel more comfortable about refactoring your code because you would detect any new bugs that your refactor introduced and so you could fix them directly.

Units tests makes you think harder about your design issues and so make you understand them *better*, if it's easy to test a piece of code or a part of your application so it probably means that the code is wellmade and it's responsability is under control. On the other hand, if it's difficult to test your code, maybe your solution could be better designed.

Units tests play along with your documentation, read clear and concise tests help other developers to better understand your codebase.

In short, if you make a framework, **make units tests** !

You can read the [PHPUnit](https://phpunit.de/getting-started/phpunit-8.html) documentation if you wanna start to make some.

## Use dependencies

Making a framework is a challenge, a challenge so time consuming that you can allow yourself to use external dependencies.  
Wanna make a framework because Symfony/Laravel/Zend are not suited for you ? Ok, so you'll rewrite everything from scratch, but maybe you did like Doctrine, why would you rewrite an ORM ? Use your favorites dependencies to make your life easier.

To keep it a challenge, make your framework agnostic from how it handle database, how it handle routing and so on...  
It is quite good for your framework if you leave to your users the possibility to use their tools inside your framework. Some would prefer Doctrine over Eloquent, other would rather use FastRoute than AltoRouter, ...

Well, use dependencies, let your users use some aswell.

## Don't silence errors

I saw things like this in some codebase :

```php
$myVariable = @function($param1, $param2, null);
```

Silencing a potential error in your framework would make debugging very difficult, **don't do it**.  
If your code can result in an error, it would be a better idea to handle this with exceptions.

## Handle exceptions

When developing a framework, it is quite crucial to know when things go wrong, to handle this, it is a good idea to warn your users or yourself about errors that happened during the framework execution.

It allow a better development workflow for you and your community.

```php
<?php

namespace Framework\Http;

use Framework\Http\ResponseInterface;
use Framework\Http\Exception\BuildResponseException;

class Response implements ResponseInterface
{
    private $content;
    private $code;
    private $params;

    public function __construct(string $content, int $code = 200, array $params = null)
    {
        if (strlen($content) <= 0) {
            throw new BuildResponseException('A Response cannot be empty.');
        }

        $this->content = $content;
        $this->code = $code;
        $this->params = $params;
    }

    public function buildResponse()
    {
        // ...
    }
}
```

The example is pretty simple, if the user tries to build an empty response, it would throw `BuildResponseException` that you can catch in your framework execution. It send a clear and understandable message for the user that he isn't using your class `Response` in a correct way.

## Handle database

If in your framework you want to create a database layer to handle it, you can do it, but please don't use [mysql](https://php.net/manual/en/book.mysql.php) functions, they are deprecated, not supported in PHP7 and have no object oriented interface.

You should look after [PDO](https://php.net/manual/en/book.pdo.php) or [mysqli](https://php.net/manual/en/book.mysqli.php) (PDO by personal preferences)

## Document yourself

Put every odds by your side, and update yourself about the languages that you're going to use, know the good practices, the existing tools, ...  
Wanna make a framework ? Document yourself first, get a little bit of experience with other frameworks to see how they work, to get inspired.  
Wanna make a tool/CLI ? Look at what is already existing that don't differ that much with what you wanna create, this would help to see what is missing from the other tools and what should be implemented in yours. Read the communities comments on what should current tools do better, etc...

Making a **useful** project is by far more gratifying than making something to leave it rot.

Don't copypasta existing frameworks aswell, there is already too many CodeIgniter-like on [/r/php](https://www.reddit.com/r/PHP). *(Code igniter being far from a reference in terms of good practices)*  
Inspire yourself from what's existing but don't brainlessly copypasta.

## Conclusion

Making a framework *from scratch* is a challenge, I strongly encourage you to use one or more frameworks before making one.

It's still an excellent exercice to better understand the other frameworks, the language that you're using and overall to be a better developer.

If you wanna jump into this adventure, well first, **good luck !** It's a very time consuming exercice which takes a lot of patience, but you'll get out of it accomplished ! :p

There, some additional links for you if you wanna know more about making a framework :
* https://symfony.com/doc/current/create_framework/index.html
* https://phptherightway.com/
* https://github.com/PatrickLouys/no-framework-tutorial (yep, even if you making your own framework !)

And some more themes and resources in which you should be interested :
* [PHP Stan](https://github.com/phpstan/phpstan) is a analysis tool that warns you about errors before even running your code or before writing units test.
* [Dependency Injection Container](https://openclassrooms.com/fr/courses/1279096-introduction-a-linjection-de-dependances-en-php) It's in french (sorry) but examples talks for themselves, it introduce you to dependency injection container, which is an important topic when developing a sophisticated and maintainable framework.

---

Resources:
- https://www.reddit.com/r/PHP/comments/awn0mn/wolff_my_own_framework_looking_for_feedback/
- https://www.reddit.com/r/PHP/comments/aj3w60/i_created_my_own_micro_php_framework_looking_for/
- https://www.reddit.com/r/PHP/comments/aca983/apex_framework_part_three_feedback_requested/
- https://phptherightway.com/
- https://symfony.com/doc/current/create_framework/index.html
- https://github.com/PatrickLouys/no-framework-tutorial
- https://www.php-fig.org/psr/
- https://dzone.com/articles/top-8-benefits-of-unit-testing
- https://stackoverflow.com/questions/1032161/what-is-the-use-of-the-symbol-in-php
- https://phpunit.de/getting-started/phpunit-8.html
- https://stackoverflow.com/questions/12859942/why-shouldnt-i-use-mysql-functions-in-php
- https://www.grafikart.fr/tutoriels/namespaces-563
- https://en.wikipedia.org/wiki/SOLID
- https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design
- https://github.com/phpstan/phpstan
- https://openclassrooms.com/fr/courses/1279096-introduction-a-linjection-de-dependances-en-php
- https://secure.php.net/docs.php

Few tips for building frameworks

Recently, I started to work with PrestaShop for my studies, I've noticed that you need to create a lot of small modules for almost anything in PrestaShop.

To make development easier I've made a [module generator](/prestashop-module-generator), with few clics you can get a complete working PrestaShop module ready to install.  
With a bit more of configuration you can get samples for an admin controller, front controller, model and so on.

The tool is completely free, don't hesitate to tell me if there are any bugs or if you want to make suggestions !

Articles

Build lobby based online multiplayer browser games with React and NodeJS

Introducing Stripe payment into your PHP projects

WordPress - A minimalist post loader

WordPress Ajax - An object oriented way

Few tips for building frameworks

PrestaShop Module Generator