Child pages
  • [custom] Issue with having too many files under Units/Sections
Skip to end of metadata
Go to start of metadata

Imported From:

Hi everyone,

We have recently came across the issue when in some projects we have too many PHP files in a single Units/Sections folder of Custom module.  As you might know this folder contains Extended classes which are used to override default functionality of  In-Portal. As a result it's getting very hard to quickly locate necessary files once you reach 20+ files in there, plus they all start with e_OriginalFileName.php.

At this point, we should throughly discussion all options of making this simpler to work with. I ask everyone (including Intechnic employees) to participate in this critical decision making process.

For now we see 3 options here, but ready to look at other options too:

  1. under Units/Sections we create a sub-folders for each corresponding Unit name (that are extending) and put replacement files inside (ie. /modules/custom/units/sections/orders/e_order_eh.php, now it is /modules/custom/units/sections/e_order_eh.php)
  2. create sub-folders for each corresponding Units name (that are extending)  the same way as in #1, but on the level up (ie. /modules/custom/units/orders/e_order_eh.php)
  3. do the same way as in #2, but re-create original module structure (ie. /modules/custom/units/in-commerce/orders/e_order_eh.php) similar to what we do with Replacement Templates now.

Again, the goal of this change is to quickly locate required file by folder tree and logically. Of course, these change will be backwards compatible.

Please speak up on what you like or don't like in the above, or propose new ideas!

Related Tasks

MCUS-8 - Getting issue details... STATUS


  1. In 2. and 3. approaches we need to create new simple unit config file (like
    in "custom/units/sections/sections_config.php"). This should be done to
    avoid class file path specifying during class extending.

  2. Hi everyone,

    I have thought over over this again - I am for 1st option (
    /modules/custom/units/sections/[ORDERS]/e_order_eh.php), here is why:

    1. We need to know which Units being replaced, the best way is to look for
    them in Custom/Units/Sections folder. In case if they are all together in
    custom/units folder - it's going to take an extra moment to recall which
    ones were replaced. This will save time.

    2. We need to escape the need of adding Config files for these replacement
    classes - it's just additional work for no reason. I believe it's easy
    enough to specify additional folder in the path of class definition, plus we
    know that all replacements are defined in a single sections_config.php which
    good - single place to go. This will save time.

    3. Even though it adds another folder level, but it's clearly better in
    terms of time spend locating the files in case of large customization

    4. I believe, no system changes will be required, plus it's 100% backwards

    Let us know what you think!


  3. Sad, but looks like Gleb, Erik, Nikita and other developers have nothing to
    add here...

    Alex what do you think on my previous post? Makes sense to you?


    Best regards,

    Dmitry A.

  4. It makes, sense. Let's try this approach one a new project, when we'll got
    one to see how it goes.

  5. I agree with you, Dmitry. 1st approach seems to be best of these 3.

    Additionally, I suggest to rename "sections" folder under ALL modules,
    respectively, also rename "sections_config.php" file. Word "sections"
    reflects only one of several functions of this file & folder. I would
    rename it to "module" folder and "module_config.php" file. It would be
    more clear to people starting to use In-Portal, because folder & file
    contain module-vice code & files.

  6. Yes, I believe Sergey is right here.

    I gave some some serious thoughts to this and see "module_config.php"
    telling us know then just "sections_config.php".

    The only issue is that we have "modules" folder (Unit) in CORE which can add
    some confusion for new developers, plus they will be next to each other.

    Alex, what are your thought on this?


  7. Since we use "section" term for naming 4 absolutely different aspects of
    In-Portal usage:

       - permission section
       - section (as category)
       - configuration section
       - tree section

    then this won't create more mess, then we already have.

  8. Ok, then we need to create a Task and Decide on Version for this change -
    5.1.x or 5.2.0?


  9. This just an approach. But, since we have some extended units in "custom"
    (Development Kit) module, then we can do it in 5.1.2 if you want.

  10. Okay, just wanted to see if we are up to doing this in 5.1.2 since it's
    heading our way soon!

    Alex, other guys?


  11. No need to do it soon. It's just an idea even without implementation.

    On Sun, Feb 20, 2011 at 4:44 AM, Dmitry A. <> wrote:
    > Okay, just wanted to see if we are up to doing this in 5.1.2 since it's
    > heading our way soon!

    > Alex, other guys?

    > DA

  12. Well, I would actually like to have it implemented into the Custom module
    for 5.1.2 if it's okay with you.


  13. Yes, you can do that.

    On Sun, Feb 20, 2011 at 8:53 PM, Dmitry A. <> wrote:
    > Well, I would actually like to have it implemented into the Custom module
    > for 5.1.2 if it's okay with you.

    > DA

  14. Here is a task:

    1007: Minimize number of Extended Units in Sections folder

    MCUS-8 - Getting issue details... STATUS


  15. This change has been committed into Custom Module 1.1.x branch and will be
    available starting Custom 1.1.2-RC1 and Custom 1.1.2 releases.