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

Making WordPress.org noreply at wordpress.org
Thu Jun 28 15:20:31 UTC 2018


#3692: Add CamelCase support from plugin names as per PSR-4 Autoloaders standard
------------------------------+------------------------------------
 Reporter:  KestutisIT        |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Plugin Directory v3.0
Component:  Plugin Directory  |  Resolution:
 Keywords:                    |
------------------------------+------------------------------------

Comment (by KestutisIT):

 Replying to [comment:2 Otto42]:
 > I'm sorry, I read through all this and I still don't understand what the
 goal is here.
 >
 > If the goal is to have capital letters in the plugin slug, then I'm
 going to have to say no, and close the ticket with a wontfix.
 >
 > Plugin slugs are all lowercase, they are used for the URL of the plugin
 in our directory, they are used as the foldername for the plugin itself,
 and they are unique entities in the system.
 >
 > Adding support for non-lowercase letters would also require additional
 code to prevent issues where somebody makes "exampleslug" vs
 "ExampleSlug", which would work on a unix based hosting, but not a Windows
 based one.
 >
 > If you want to code your plugin code to a specific standard, then you
 can do so if you wish. But having it located in a folder using lowercase
 letters only is not really a very large burden to bear.
 Well, as mentioned before this small-feature-lack is like a backbone for
 very high scyscraper, and it impacts (the reset of namespace back to dash
 separated after plugin’s update) thousands of plugin authors in the whole
 tree stack (S.O.L.I.D. MVC -> Some plugin, i.e. Booking -> Some extension
 for the plugin, i.e. “Villa” or “Hotel” -> Some of 100’s themes for that
 plugin extension -> And that exact theme overriding plugin view (i.e.
 /themes/AmazingWorld/Extensions/SomeCamelCasedPluginName/) name folder),
 not even talking about the fact that as per Wolf of Wall Street’s Jordan’s
 Belford’s book “Way of The Wolf” we have 4 seconds to make this believe
 for a developer starting his masters course in University to choose
 WordPress plugin for his course task and not C# and ASP.NET, and that
 would never make him believe if we have to start a talk with “well, you
 will have to make a HACK for plugin’s folder name”, and it would take then
 8 additional long meetings to make him believe in WordPress again, and as
 Guttenberg is not just WordPress anymore, the greatest idea to start is to
 say that to make a solid WordPress plugin you don’t have to learn any new
 coding standards, you can just port your C# code library with small
 changes straight to WordPress in a day due to S.O.L.I.D. MVC + Templates
 that follows all these PSR-2 & PSR-4 Autoloader coding standards that is
 pretty much a status-quo in JAVA an C# OOP world for a decade already.
 The first question you need to ask if you do believe that WordPress in
 just just WordPress anymore, as Matt said, and do you want to convert
 thousands of C# and JAVA developers to WP plugin devs or not, as this will
 also pay-off the reputation of WordPress A LOT, as if you start to talk
 with C# dev or some University lecturer that you have to start from the
 HACK then it will never sell. I'm saying that we need just to add support
 for this, not to ditch the existing dash-lowercase separation, just this
 is just an addition that helps 10,000 of plugin author at Envato that uses
 EnvatoToolkit plugin concepts of SOLID MVC, as well as devs from other
 CMS'es like Php-Fusion, and other languages. Because autoloaders and
 namespaces will then won't work who prefer to follow the default global-
 use coding standards. And EVEN the HACK won't work well, as for
 "/GreatMVC_Tests/" it will give you the "great-m-v-c---tests" URL in W.ORG
 instead of "great-mvc-tests" URL that we want. And this can be solved with
 just one line of support for "Namespace" META header for plugins, and can
 have the SAME SLUG for URL's and translations. Meaning we need to allow
 this only for the folder names to follow the correct PSR-4 Autoloaders
 standard, so that everything, even PHPStorm IDE with have it defaults to
 work well without additional renames for everyfile, especially if you have
 a TREE-REFACTORING.

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


More information about the wp-meta mailing list