-
Notifications
You must be signed in to change notification settings - Fork 17
Does not work with 6.0 #39
Comments
I think, or at least I hope @keywan-ghadami-oxid is working on this module to make it work on 6.0 |
I have a working version, PR is coming |
If @ellisv has no more time for project, we can maintain it within the community. In that case I suggest to give some volunteers(including me) access to https://github.com/OXIDprojects/oxid-console and maintain a fork. About 6.x support, i am willing to maintain/do that, but i am by my self not yet an early adopter of version 6 so i am looking forward to see the pull request from @alfredbez. |
Maybe that's a good point to refactor the whole application and build it on the Symfony Console Component, Namespaces and stuff like that (provide a |
Did you have a look at the 1.3 branch? @ellisv already started with that, but i am not sure about the current status. Btw i would prefer to have the console version independent from the oxid shop, that makes it easier for me to maintain stuff because i could use the same version in all projects. |
@alfredbez Totally agree on refactoring application to use Symfony console component, now especially when oxid has composer support this makes sense more than ever. As keywan already mentioned I've started to work on this on 1.3 branch but it was forgotten for quite some time. @keywan-ghadami-oxid I am going to resume to work on 1.3 this weekend. |
I just checked out the 1.3 branch: Awesome! I started yesterday to refactor this using symfony console, because I didn't know that you're actually working on that. If there is anything I can do, just let me know. |
@ellisv If I don't got it wrong,
|
1.3 oxid-console installation will be through composer only, so you can install globally and run oxid console commands in a directory where shop source lies, or in a project itself if it has composer support. And I see you concern, as you'll put oxid-console dependency in composer.json with proposed shop structure what you'll have to do is to be in
And take in account that value when bootstrapping shop in oxid console. We could also have some common name checking in there too, so configuration would be optional for most setup, but we need that kind of option if your project structure differ. Do you agree? |
Global installation is a cool feature. For local installations (per project) I would like to see a similar approach like artisan in the laravel framework, where the console-script is outside of the webroot. We can then also drop the htaccess-stuff. What do you think? |
In order to have oxid console executable in oxid project directory itself (non vendor directory) we would have to make people to put it there manually (as we do it now). Going with |
Hi there is a oxid 6 compatible port available |
oxid-console does not work with OXID eShop version 6.0 (which is not released atm)
application
is nowApplication
core/interface
is nowCore/Contract
sConfigKey
isn't defined inoxconfk.php
anymore (it's here now)oxModuleInstaller@_addModuleSettings
doesn't exist anymore, instead you have to use the new SettingsHandler (example)The text was updated successfully, but these errors were encountered: