- 🇬🇧United Kingdom catch
da/di/o1/st/d9/w/m/cb/webform/m/weopcuente/weopcuente.info.yml
Replacing human readable directories with two character abbreviations isn't a simplification.
Path lengths and directory+file depths have gotten out of control and now commonly approach 256 character lengths and 10 + levels of directory depths (nesting) in contrib modules. This is preventing multisite hosting+ solutions like AEgir from "discovering" everything they need to see and will require ever-deeper nested-level searches, consuming both extra RAM and CPU server-side, and extra time and work developer-side.
Furthermore, although Moore's Law seems to still be more-or-less in effect, the necessity of DB field lengths of 512 characters + for simple paths+file names, and the parsing in flat-file or NoSQL DB's of the same - does actually use up both RAM and CPU.
Furthermore, since Drupal is moving towards decoupled, headless use, etc. it would be wise to reduce, simplify, and conform drupal path structures and file names to a new standard and require contrib developers to conform. To be an effective competitor in this field of computing, drupal needs to be lightning fast!
Although writing out path names and file names with long human-readable words separated by underscores simplifies the task of module and theme development somewhat, this should not be allowed to block the adoption of this initiative, since once a new standard is confirmed, then development will become easier and easier with usage.
I propose to reverse course completely in Drupal 11 (It's probably too late for 10 adoption) and require radically shortened and simplified directory names and file names.
Quite simply I propose that all directory names be shortened to 2 characters, with the most commonly used directories shortened to 1 character. In addition, I propose that file names be given only a sequence of characters (letters and numbers strung together), every two of which stands for a word. [The only restrictions I see would be to reserve (not allow) the list of 2 letter language codes and country codes]
Thus the directory:
/core/ would become /c/
/modules/ -> /m/
/themes/ -> /t/
/files/ -> /f/
/all/ -> /a/
/translations/ -> /t/
/languages/ -> /l/
/standard/ -> /s/
/profiles/ -> /p/
/default/ -> /d/
/web/ -> /w/
/contrib/ -> /cb/ (co is reserved)
/custom/ -> /ct/ (cu is reserved)
etc.
and filenames also:
webform_bootstrap_test_theme.info.yml -> weboteth.info.yml
webform -> we
bootstrap -> bo
test -> te
theme -> th
so that this path which recently prevented me from doing db updates on d 9.3.6 (from webform 6.1.3):
data/disk/octp1/static/d9/web/modules/contrib/webform/modules/webform_bootstrap/tests/themes/webform_bootstrap_test_theme/webform_bootstrap_test_theme.info.yml
becomes:
da/di/o1/st/d9/w/m/cb/webform/m/webo/ts/t/webotet/weboteth.info.yml
159 characters reduced to 67
This is a full path on a BOA - AEgir multisite hosting platform.
and
data/disk/o1/static/d9/web/modules/contrib/webform/modules/webform_options_custom/tests/modules/webform_options_custom_entity_test/webform_options_custom_entity_test.info.yml
becomes;
da/di/o1/st/d9/w/m/cb/webform/m/weopcu/ts/m/weopcuente/weopcuente.info.yml
174 characters reduced to 73
So that rather than expanding DB fields which contain paths + filenames to 512 characters or more, we could safely reduce them to 128 characters, perhaps even 64 if the reduction and simplification were truly enforced everywhere - for example in module and theme names (machine names, of course, not display names).
One additional file could be put in the info area of each module and theme - a simple key-value list of what each one-character and each two-character "code" represents. These "codes, or key-value pairs should be standardized as much as possible and drupal developers should be required to conform to their usage. Of course, each module or theme would have to have a separate file, since there will be customizations and specifics.
This file could be called "module-name/key.info" for example.
it would look like this:
module-name:webform (or we if we really do this right - give module and theme names an abbreviated machine name)
version:6.1.3
core:c
modules:m
themes:t
files:f
all:a
translations:t
languages:l
standard:s
profiles:p
default:d
web:w
contrib:cb
custom:ct
webform:we
options:op
entity:ey (en and et are reserved)
etc.
2) Furthermore, a conformity to a more reasonable, reduced, simplified standardized directory structure which discourages or even forbids directory depths of more than 3 or so levels in modules and which "flattens out" the directory structure in code and other code should be required.
Thus:
data/disk/o1/static/d9/web/modules/contrib/webform/modules/webform_options_custom/tests/modules/webform_options_custom_entity_test/webform_options_custom_entity_test.info.yml
could become:
data/disk/o1/static/d9/web/modules/contrib/webform/modules/webform_options_custom_entity_test/webform_options_custom_entity_test.info.yml
which would be reduced to:
da/di/o1/st/d9/w/m/cb/webform/m/weopcuente/weopcuente.info.yml
174 characters reduced to 62
and with a reduced machine name for teh webform module of "we"
174 characters reduced to 57
and a 64 character length db field length is achievable everywhere.
N/A
Convince the Drupal commuity that the benefits of doing this far outweigh the costs and labor!
None
As described above - a complete standardization, simplification and reduction of file names and paths, to which all developers would be required to conform!
As described above - a complete standardization, simplification and reduction of file names and paths, to which all developers would be required to conform!
Closed: works as designed
Idea
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
da/di/o1/st/d9/w/m/cb/webform/m/weopcuente/weopcuente.info.yml
Replacing human readable directories with two character abbreviations isn't a simplification.