[wp-meta] [Making WordPress.org] #3692: Add CamelCase support from plugin names as per PSR-4 Autoloaders standard

[Making WordPress.org]

#3692: Add CamelCase support from plugin names as per PSR-4 Autoloaders standard
------------------------------+-----------------------
 Reporter:  KestutisIT        |       Owner:  (none)
     Type:  enhancement       |      Status:  reopened
 Priority:  normal            |   Milestone:
Component:  Plugin Directory  |  Resolution:
 Keywords:  close             |
------------------------------+-----------------------
Changes (by dd32):

 * keywords:   => close


Comment:

 As said at the WCEU Contributor day by myself:
  - The plugin directory internally relies upon the WordPress
 "slugification" process in many ways, and is an integral part of how the
 directory operates. This is relied upon by Core Updates, SVN Interactions,
 linking of plugin posts & svn directories, and a huge number of other
 random things behind the scenes.
  - WordPress has hooks and filters in place to allow plugins/3rd parties
 to change how slugs operate. The Plugin Directory will not be leveraging
 those to allow !CamelCase (or other) formats to work for hosted plugins.
 Hosted plugins come with rules, restrictions, and expectations of authors.
  - The plugin directory expects slugs to be in a standard WordPress 'slug
 format', and won't be changing that. Changing it has implications far
 exceeding the intended effect, and would cause unintended consequences.

 As some background to slug generation in WordPress:
  - Any request to change how WordPress itself generates slugs should be
 directed to the Core Team. You can dig up the code references yourself,
 it's all open-source (as is all the plugin directory).
  - WordPress slugification exists as it is to provide a "clean" url-safe
 string. There are no plans to change how that operates - other than make
 it more strict and remove any further edge-cases that exist (Historically,
 multibyte characters fall into that category)
  - WordPress does have filters in place to allow a plugin or 3rd party to
 modify how slugs are generated. The Plugin Directory has no intention to
 utilise them though.

 To go back to one of your examples as suggested why this change should be
 made:
 {{{
 For the file, name as "/wp-
 content/plugins/GreatMVC/Models/Item/ItemsObserver.php", you have to have
 a starting line of:
 <?php
 namespace GreatMVC/Models/Item;
 }}}
  - There's nothing preventing you from doing that in your own code.
  - If you want to release it publicly, you need to expect that your plugin
 directory can and will be changed by others
  - If you want to release it within the WordPress.org plugin directory,
 you need to accept it's limitations and one of those is directory slugs
  - Lots of plugins use PSR-* in their code, there's no reason you can't
 either.
  - To use PSR4 classes, you simply need to namespace it to your plugin.
 ie. `GreatMVC/Models/Item/ItemsObserver` exists within the file relative
 to the loader of `plugins/great-mvc/Models/Item/ItemsObserver.php` or even
 `plugins/great-mvc/GreatMVC/Models/Item/ItemsObserver.php` (if you really
 need the full path) or `plugins/great-
 mvc/vendor/GreatMVC/Models/Item/ItemsObserver.php` (as many other plugins
 do).

 In general plugins & themes should not expect to know the file path to
 other plugins, or need to know what folder they're being loaded from.
 Plugins and Themes may not always live where you expect, and as a result
 every plugin and theme should be self-contained with no inter-plugin
 dependancies. As a result, what the slug of your plugin or theme is,
 should be completely irrelevant to your code and PSR coding notions.
 Themes could be loaded from `wp-content/themes/`, `wp-
 content/common/themes/pub/` or even `wp-content/plugins/some-plugin
 /included-themes/`
 Plugins can be loaded from `wp-content/plugins/`, `wp-content/mu-plugins/`
 or even `wp-content-common/sites/plugins/`.


 I'm not closing this ticket (despite firmly believing this is a
 `wontfix`), as I don't want to get into a close-reopen war with you.
 This is also my final (And only) comment on this issue, as this is all my
 opinion, and it won't be changing.

 Consider taking a step back and looking at how you can make your coding
 style and preferences fit within the WordPress ecosystem. I'll freely
 admit WordPress has some limitations, but those limitations cause
 standardisation and wider code acceptance, many developers may initially
 hate it (or love it) but have been able to adapt from other languages or
 platforms without significant barriers, while still maintaining their
 previous coding standards (good or bad).

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/3692#comment:10>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org