Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.All Drupal PHP code should be in it's own namespace.
By declaring the namespace at the top of each PHP file, it automatically prefixes functions and classes with 'Drupal\' . This means that the 'drupal_' prefix can be removed from function names and 'Drupal' removed from class names.
Advantages
- It prevents namespacing collisions with functions and classes in other PHP software, e.g. #1370032: render() function defined by other PHP libraries.
- We don't have to prefix our functions to prevent the above problem from happening. Currently some functions are prefixed and some are not.
Prefixes are used for our PHP Wrappers , but because this is not the only use of prefixes it is not a reliable way to determine if a function is a PHP wrapper or not.
It is not the case that it can be determined if a function is defined by PHP or Drupal by looking at the name. Most Drupal functions are not prefixed.
Removing the Drupal prefix from all functions that are not PHP wrappers removes ambiguity. It also makes the code much more readable. We do not need to continually declare that every function is part of Drupal when we are in our own codebase!
- It paves the way for potentially putting each module in it's own namespace.
I have managed to put all of Drupal 8 into it's own namespace with 100% of tests passing.
How it works
A script does most of the heavy lifting. This is followed by a patch that tidies everything up and ensures that all tests pass.
Both are attached. There are also two binary files attached. These files are gzipped PHP files and so couldn't be included in the patch and must be placed in core/modules/simpletest/tests/upgrade .
The script:
- puts 'namespace Drupal;' at the top of every file.
- imports any global classes that the file needs with the 'use' command.
- removes 'drupal_' from function names except all PHP wrappers and
- drupal_static() / drupal_static_reset() - this would be shortened to just 'static' which is a reserved word. In a way it can be considered a PHP wrapper.
- drupal_render() - there are currently two functions: drupal_render() and render(). I couldn't determine how best to rename these functions.
- drupal_goto() is renamed to redirect() because 'goto' is a reserved word. This also brings the terminology into line with the form api.
- removes Drupal components from class and interface names
- fixes drupal_static_reset() calls. The identifier is typically a function name and so must be prefixed with 'Drupal\'
The patch fixes all the tests. This primarily consists of fixing dynamic function calling - Drupal invokes a lot of functions like this, e.g. module hooks. Anytime a function or class name is referred to in a string, it must be prefixed with 'Drupal\' .
The testbot will fail because Drush does not understand namespaces.
I would encourage you to browse the consolidated patch or apply the patch and browse your favourite file to see what the changes look like.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | namespace.php_.txt | 4.44 KB | jbrown |
| #11 | namespace-fixes.patch.txt | 217.74 KB | jbrown |
| #11 | namespace-consolidated.patch | 1.78 MB | jbrown |
| #9 | namespace.php_.txt | 4.45 KB | jbrown |
| #9 | namespace-fixes.patch.txt | 217.96 KB | jbrown |
Comments
Comment #2
jbrown CreditAttribution: jbrown commentedAttaching updated patches that can be applied with git...
Comment #3
tim.plunkettSo the testbot will run.
Comment #5
jbrown CreditAttribution: jbrown commentedThe bot wont test it as drush doesn't understand namespaces.
Comment #6
tim.plunkettWell, in this case it failed because of #1260716: Improve language onboarding user experience which was committed earlier today :)
Reroll. diffstat is the same.
Comment #7
tim.plunkettOkay, so you're right, the testbot does fail pretty hard on this, but at least the patch is applied.
Is there an issue for this already?
Comment #8
jbrown CreditAttribution: jbrown commentedNope.
Comment #9
jbrown CreditAttribution: jbrown commentedUpdated for CamelCase Drupal namespace and reroll.
Comment #11
jbrown CreditAttribution: jbrown commentedReroll - again the testbot will fail because drush can't test namespaced code.
Comment #12
jbrown CreditAttribution: jbrown commentedComment #14
jbrown CreditAttribution: jbrown commentedComment #15
donquixote CreditAttribution: donquixote commentedLook..
the problem I have with this:
Today we say that every file needs a "namespace Drupal;" -> biiiig commit, big noise in git history.
Tomorrow we say that core files need a "namespace Drupal\Core;" -> another big commit, making the previous one totally redundant.
What's the benefit, if we already know that just "Drupal" won't be the full story?
Comment #16
donquixote CreditAttribution: donquixote commentedOk, if I understand correctly, then a subsequent patch (Drupal to Drupal\Core) would be easier, because a lot of work has already been done?
EDIT:
Yes, looks like there is really a lot of valuable work in here. Even if we change Drupal to Drupal\Core or something else, we can benefit from this work.
Comment #17
jbrown CreditAttribution: jbrown commentedYeah - let's say hypothetically it was decided that all Drupal PHP code should be under namespace Drupal with non-module code being under Drupal\Core (and later Drupal\Component ) and that modules should be under namespace Drupal\Module\modulename .
First of all a patch from this issue would go in as it is the lowest common denominator.
Then a patch from another issue would put core into Drupal\Core (and put
use Drupal\Core;into module files, prefix function calls from a module into core withCore\).Then a patch from another issue would namespace module code. Core shouldn't be making any calls into modules, but this is not the case, e.g.
use Drupal\Module\Systemwill have to be put into some core files. Namespacing will make it clear that this is a problem to be rectified.Comment #18
dkinzer CreditAttribution: dkinzer commentednamespace-consolidated.patch queued for re-testing.
Comment #19
sunGiven the PSR-0 conversions already happening for D8, this issue looks obsolete to me.
Comment #20
donquixote CreditAttribution: donquixote commented@sun,
I don't think so.
There is quite a disagreement (also on gdo) about whether procedural code and hooks need to be namespaced.
The PSR-0 discussions all explicitly say that they are all about classes, and don't care about procedural.
So, we could rename this issue or "wontfix" it, but it's definitely not a duplicate.
---------
For the namespaces for procedural code, the vital questions are:
1) How fragile is the current situation exactly? (for nameclashes)
2) How long will procedural code and procedural hooks be around in Drupal?
3) How important is it for us to make our procedural code cross-platform?
4) Is it worth the effort?
Some (webchick) say (on gdo, will add link some time later) that those nameclashes are a rather theoretical issue, and we should just name our modules properly (what that means, has yet to be said).
I imagine that a lot of them might go unnoticed, and could be responsible for some miraculous bugs that have been around forever.
I currently can think of exactly one case where a nameclash did happen (sth core vs contrib).
The bigger practical problem for me is the preemptive paranoia when naming modules and functions. E.g. if nowadays I had to redo admin_menu and menu_block, i would rather call them adminmenu and menublock, in fear of prefix collisions. This is pretty annoying.
Comment #21
RobLoachWe should rather leave our procedural code as it is and instead put in effort to "do it right" by moving them towards object-orientation. I'm with sun on this one. Namespacing public functions doesn't actually benefit us. It's like sticking lipstick on a pig.
Comment #22
donquixote CreditAttribution: donquixote commentedThere is OOP code out there which is just as ugly as, or even worse than our procedural code.
For my taste, procedural can stay around for a much longer time, while we slowly migrate those things to OOP that actually benefit from it.
[EDIT 2023] Whether or not this was true at the time, I wrote it, we are far beyond this point. I no longer stand by this statement :) [/EDIT 2023]
In the meantime, I personally would be happy about namespaces in procedural and hooks, if only to fight my paranoia.
Besides, so far I have not seen a convincing OOP replacement for procedural hooks. We might see something emerge in D8 contrib, but this would still have to prove itself.
-----------
I suggest we keep this issue or another one as a place to discuss.
Comment #23
donquixote CreditAttribution: donquixote commentedSince OOP code is already dealt with elsewhere, I think we should rename this issue.
-----------
For those who don't see the point in doing that, here is an example I just ran into.
For a project I want to create (http://drupal.org/project/htmltag), I would like to have a
function htmltag_attributes()
This thing is supposed to be a simple factory, that should return an object of type htmltag_TagAttributes.
Now,
https://www.google.de/search?q=drupal+hook_attributes
it looks like hook_attributes() is a name already taken, although it is hard to tell if this is a regular hook, or something with a special mechanic (where my function might not count as an invocation).
And even if it's not, who knows if something in the future won't declare hook_attributes() as a regular hook.
This uncertainty makes me rethink the function name of "htmltag_attributes()", so I might name it "htmltag_tag_attributes()" instead, which is totally pointless, and just a wild guess that this won't ever collide with a hook.
Comment #24
donquixote CreditAttribution: donquixote commentedHm, this rename was a bad idea. We already have plenty of those issues around, and renaming will only make them less distinguishable.
So, partial revert of the rename.
Comment #24.0
donquixote CreditAttribution: donquixote commenteddrupal => Drupal
Comment #37
smustgrave CreditAttribution: smustgrave at Mobomo commentedWonder if the issue summary could be updated around D10.