Closed mariolorenz closed 4 months ago
Hi, sorry but I don't quite understand your request. This component creates a ".ide-helper.php" file under the modules directory. This file then contains the module extensions of the shop based on the shop's module chain hierarchy. It will consider the installed modules of the underlying shop (as registered within the shops boundary). At the moment, it will not consider if the module is active. This has the effect, that you do not have only the LSP support of the OXID parent class, but of the complete class extension chain of all installed modules. The other tool only generated the reference to its parent class, and does this through manually scraping the metadata files within the modules folder, thus ignoring modules that might be located elsewhere. For my workflow I like the chain more. But it should not be a great hassle to create a mode, that does the same as the proudcommerce script. It also would be possible to make per module basis within the modules folder by referencing the module id or path.
Sorry, I didn't see it straight away. I thought that the .ide-helper.php in the root was created by your tool. I didn't pay attention to the timestamp. This file was created by the OXID tool. I have now also found the /var/www/source/modules/.ide-helper.php. Unfortunately it is empty in an OXID7 system, since the modules are no longer in source/modules/, but usually in the vendor directory. I don't know how to solve this yet. When we develop modules in OXID7, the modules are located locally in an extensions folder. During composer-install, only symlinks are created from there. So your tool should find all the paths where the module can be located. Sounds complicated ...
There may be a misunderstanding here. My tool does not search any modules anywhere. It uses OXID's internal module chain service (ClassExtensionsChainDaoInterface). Thus, all modules known (installed) to OXID are evaluated and used for the ide helper file. Actually, there is still a bug that may generate an empty file when used with EE edition (multi shop). In this case you need to set the shop id explicitly:
vendor/bin/oe-console gp:ide:helper --shop-id=1
I am sure, that it works fine since I am using it in several projects (CE/PE/EE). But I have not bothered fixing this bug, because it is mostly used automated or aliased. But if others want to use it, I could fix it within 24 hours. I also can change the default location for the generated file if the current location may be bothersome.
I have tested it with OXID CE 7, this is the example output:
Good evening,
Now I had time to take a closer look. Sorry for the confusion, I was confused by the storage location. In OXID7 you still save the file under source/modules/. The OXID .ide-helper.php is in the root. I drew the wrong conclusions from this. I thought yours must also be in the root. In the end you are right, everything works as you described. The tool found all the paths. No matter where the modules are now. It is a very helpful tool. I will present and recommend it in our OXID dailies this week.
Regards, Mario
Hello, I found your oe-console-extension. It is a very nice replacement for the OXID original.
What do you think, can you imagine extending it to the modules in the installed system?
There is a version for OXID6 from our colleagues at ProudCommerce: https://github.com/proudcommerce/oxid-ide-modulehelper Unfortunately it is not compatible with OXID7 and it is not quite as flexible. Composer support is missing, for example. Nevertheless, the tool is not bad for an OXID6 shop. It would be better if it ran via oe-console, like your tool.
Maybe you have time. I would be very happy and would recommend it to all my colleagues at OXID.
Regards, Mario Lorenz (OSC-Team, OXID)