Include Composer autoloader in the plugin

[szepeviktor]

Requires PHP: 7.2

We could include Composer's autoloader AND put all of our classes in 1 directory. Now there are two orphans

• ./public/class-decalog-public.php
• ./admin/class-decalog-admin.php

Of course we still need our own autoloader as this project follows WPCS which - I think - will be deprecated as soon as core gets a namespace.

[szepeviktor]

I would welcome PSR-4 naming as this class-*.php nonsense resembles PHP 5.2 Also see Automattic's position on this.

[Pierre-Lannoy]

Hello Viktor. Thanks for your suggestions. In fact, the structure of this plugin is mainly a structure I regularly use to create plugins. I know it is not perfect, but the main goal for me was:

• to be understandable / easily "usable" by me
• to stick as much as possible to WordPress guidelines (and coding standards)

I fully understand that the first reason for this will have to evolve (because some of my plugins are now on GitHub) and that a rule that applies to me alone can be totally invalid when several people collaborate on the same code. Nevertheless, the second reason can't be erased (mainly because I want this plugin - like others - be available in the WordPress directory). Class file names (class-*.php) and nested directories are (as far as I can remember) "mandatory". Let me read again these guidelines to see if it's true, or if my usage and my coding habits, have misled me...

[szepeviktor]

All right, I am not the one to argue about it. Here are some class files with PSR-4 names: https://github.com/Pierre-Lannoy/wp-decalog/tree/master/includes/libraries/monolog these could easily be Composer autoloaded.

[szepeviktor]

• I'd also leave WPCS-named classes the way they are now
• rearrange the two orphan classes
• load libraries with Composer (vendor/composer/* files)

You could also load our custom WPCS autoloader in Composer's autoload/files

[Pierre-Lannoy]

Hello @szepeviktor ! I have turned in my head countless times your proposals. And they make total sense, and are in the direction of a qualitative gap in the code itself and in its maintenance. However, as long as WordPress does not have a libraries (and dependencies) manager, this can only lead to risks:

• namespace collisions
• version incompatibilities (and potential collisions too)
• non-compliance with WordPress standards (this last point being very critical because of the validation - or not - of DecaLog in the official directory).

This issue will not be fixed or improved.

Thanks again for the suggestions.

[szepeviktor]

Thank you Pierre for your lengthy response!

Meanwhile - in the 3 years of this issue - there is a result. Here is how to write modern plugins for WordPress: https://github.com/szepeviktor/small-project/blob/master/MAIN-FILE-PARTS.md 👀 some code is also include.