Skip to content

Refactor code so modules/themes/language packs can exist under different directories (such as 'vendor') #1013

Closed
@alankent

Description

@alankent

Currently we cannot leave modules (and themes and language packs) downloaded via Magento in the 'vendor' directory. We tried to convert the code, but hit a problem. TexanHogman (Rick) described it well here: #357 (comment).

The goal is to allow modules to reside under 'vendor' or 'app/modules' (renamed from 'app/code'). Currently there are file path patterns coded into the system (such as app/code///etc/module.xml) that make putting modules in different locations harder. (I personally would prefer to get the list of directories from the config.php file, worked out by the setup script, allowing modules to sit anywhere in the directory tree giving the developer greater freedom of how to lay out their code during development.)

The real problem is other areas of the code, like functional and integration tests, have too many dependencies on the current locations of files. One approach is to say "tests are only usable if you git clone the master repository". This is not ideal however. Production sites should never use git clone. They should use Composer to download official release versions of modules to ensure they are using a stable release version of the code. This is important for receiving Magento or extension developer support. So it is desirable to rework all the test cases to not depend on the current location of modules and other assets.

This work was started internally, but lowered in priority when the effort required to clean up the tests was fully understood. It is valuable, but there is other higher value / lower cost work that is being planned first. (Also note the internal project had a wider scope of changes than described in this request. This request focuses purely on allowing modules/themes/language packs to reside under 'vendor', with the goal of using Composer without modification or extension.) Offers of community contribution are welcome.

The following is a list of areas that may be affected as an illustration of types of changes likely to be needed:

  • dev/tests/static/framework/Magento/TestFramework/Utility/Files.php - quite a few paths
  • dev/tests/static/testsuite/Magento/Test/Integrity/App/Language/Package.php - glob calls
  • dev/tests/static/testsuite/Magento/Test/Integrity/App/Language/TranslationFiles.php - glob calls
  • The BP constant in the original source code has two meanings. One represents the root of the magento install, the other meaning is the directory from which source code can be found. This means all instances of BP need to be examined and either kept as is or replaced with code that uses the module directory. There were initially 140 usages of this constant.
  • setup/config/autoload/global.php - there is a 'module' directory, but the goal of this work is to allow modules to reside in multiple places so this concept probably needs to be replaced.
  • Most of the Magento product code uses autoloaders to access classes, but code in the the tests/, build/, tools/, and shell/ directories frequently access files by relative paths. There are 1780 uses of relative paths in project php files. A number of these will remain valid after file restructuring (because a whole subdirectory structure would be moved, so relative paths internal to that structure would remain valid), but our initial analysis underestimated the number of these that would need to be manually updated. These relative paths are commonly combined with variables meaning any attempt at scripting logical changes would be difficult.
  • Symbolic links not desirable because of usage of DIR in the code. DIR will be the physical location of a folder or a file. There are 1541 use cases of DIR in Magento code base.

The following is out of scope for this request:

See also #357 for related discussion.

Given the potential complexity of this task, it is recommended to come up with a proposal to allow the root directory of each module be determined and get that reviewed before commencing with implementation work.

[Warning: This request is an experiment to see how well this approach works to outsourcing work and is subject to change or being withdrawn.]

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions