Problem/Motivation
drupal_get_path() allows you to find the location of a module via the module name - this accounts for the different possible locations where a module could be installed ( contrib/, sites/SITENAME/modules/contrib etc.)
However, there are multiple uses on core where it's not necessary, because the call is inside the module being referred to.
In these cases, just __DIR__ returns the same thing (or sometimes __DIR__ . '../' if the call is in a subdirectory of the module) without having to go through all the Drupal logic.
When we eventually deprecate drupal_get_path(), this will reduce the number of replacements that need to happen. It should also make it clearer what use-cases the replacement actually needs to solve.
An obvious example is this one in statistics.module:
$settings = ['data' => ['nid' => $node->id()], 'url' => \Drupal::request()->getBasePath() . '/' . drupal_get_path('module', 'statistics') . '/statistics.php'];
A previous attempt was made in #2351919: Replace uses of drupal_get_path() with __DIR__ where possible, but either it didn't catch everything, or new uses have crept in.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | Sample_Test_Result.txt | 5.57 KB | codersukanta |
| #4 | Search_Result.jpg | 110.36 KB | codersukanta |
Issue fork drupal-3151676
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
catchComment #3
codersukanta commentedComment #4
codersukanta commentedI have searched
drupal_get_pathin drupal core and found approx 149 results in 90 files.It would be a very big patch if we replace the
drupal_get_pathfunction in a single patch. So according to me, we should spit this issue in multiple issues or we can split this module wise.Comment #5
codersukanta commentedComment #6
catchMost of the
drupal_get_path()calls can't be replaced in this issue - especially where $module or $theme is a variable, and cases where the call is referring to a different module. So it should be fine to do the ones that can in one patch.In general we try to avoid doing per-module clean-ups for issues like this since reviewing 20-30 small patches with the same kinds of straightforward changes takes longer than reviewing one.
Comment #7
codersukanta commentedComment #8
codersukanta commentedIt seems like simply replacing drupal_get_path with __DIR__ will not work. Sometimes it's breaking the file paths. Attached test cases of such scenarios.
Comment #9
siddhant.bhosale commentedComment #12
drummI’m using this issue to test out merge requests as part of #3152637: Opt-in to the Drupal.org Issue Forks and Merge Requests beta.
The commit on that merge request only covers
core/modules/system/tests/modules/batch_test/batch_test.moduleso far. The replaceabledrupal_get_path()instances I found are:Comment #14
drummLooks like
__DIR__is not the exact same thing asdrupal_get_path(), it is a full path, not relative to index.php. So not all of these replacements are straightforward, as shown by the3151676-remove-unnecessary-drupal_get_pathbranch. For now I’ve abandoned that and am looking for other types of uses.Comment #16
siddhant.bhosale commentedComment #25
dimitriskr commentedThere are no more uses of drupal_get_path() to 11.x
Some old usages have been replaced by \Drupal::service('extension.list.module');. Do we want to replace the service with __DIR__?
Comment #26
quietone commented@dimitriskr, no were should use the service.
drupal_get_path was removed in [#3269154]making this outdated.