Hi guys, sorry for posting so often on rather obvious things, but im not at all familiar on these topics.
So i’ve been trying to update the shop from CE 4.10.6 to 6.x, and up until now i’ve only managed to get the new version running on the server by downloading the shop and uploading it with Filezilla from one of the links that said this method is not recommended nor supported (go easy on me for this one:D). I’ve finished running some scripts required to update the database (used the one that said “you don’t lose your data”), and the next step was to run some migration commands ( vendor/bin/oe-eshop-db_migrate migrations:migrate and vendor/bin/oe-eshop-db_views_generate but at first i didnt even know from which working directory, and the i saw that here was a hyperlink to some Oxid eshop doctrine migration wrapper, with a link to a github project. Does that project have to be installed in the server to be able to run those aforementioned commands? and if yes where does it have to be installed (which specific directory)
Note: the server the site is hosted on is a managed instance so installing anything globally is not allowed, so using git for example is not possible. The only way is through Filezilla. Any help would be appreciated!
Edit: if you have auto-translation in chrome enabled, switch to original language cause i just noticed that the entire post was completely messed up.
The problem is that additional modules and also shop-updates have to be installed with composer. So if you cannot use composer in your webspace, you should nevertheless use it to get the files to upload. Which operating system do you use locally?
I did the same until i discovered that both scripts have to be used, one after the other.
No installation needed. Working dir is the one containing source and vendor. What error do you get?
i understood this from the start but i’m going to have to cross that bridge when i get to it since i cannot use composer on the server. My work pc runs on windows 10, but i can also use a virtual machine with a version of linux if needed.
Ran the second script as well, didn’t realise both of them have to be used since one had the word “cleanup” in it
as for this, at first i was getting the issue “No such file or directory” so when i checked vendor/bin it was empty (chris!t), but after i reuploaded the contents of that directory from my downloaded shop to the server, now i get “vendor/bin/oe-eshop-db_migrate: command not found”
Had to run with sudo because first i got “permission denied”
You need composer to install modules, so the idea is to install the shop locally with composer and then transfer everything to the server. Config.inc.php and htaccess have to be edited or created on the server by running the graphical setup on the server. If you install something, copy the changed files in source (e.g. the directory of the new module) and additionally the whole vendor directory to the server.
To install the shop locally, you can install native on windows or use the vm supplied by oxid or a docker environment. I find it more convenient to use the operating system, you can do this by:
install xampp with the same php version as your server
install composer
optional: install git
There are windows installers available for all of this. Then you can install OXID with composer locally.
There is something special about the scripts in vendor/bin. You only need them for commandline commands. When created on linux, there are symbolic links in the vendor/bin directory, which cannot be transfered with ftp. When created on windows, these are files which can be transfered to the server.
The only time these are really needed is for executing database migrations. If you create the shop locally on windows with composer and then transfer the files to the server this command should work, also check whether the php version in the shell is the same as your webserver.
I have created a module to execute migrations from OXID backend in case there is no ssh access: GitHub - leofonic/oxid-backend-migrations: OXID eShop enable database migrations in backend, but you need composer to install it.
that would make sense on why it wouldn’t work normally, however i used this link OXID Forge – The knowledge base of the OXID eShop to get the shop by simply clicking Download. And i’ve already setup a shop on the server with the package in the link.
The package available there was created using linux, so it contains symbolic links in vendor/bin that cannot be unpacked and then transfered to the server.
You can still execute database migrations. What version is displayed when you type “php -v” in the shell? If it is 7, you can execute the migration command in vendor/oxid-esales/oxideshop-doctrine-migration-wrapper/bin instead of vendor/bin, in project root:
well, the site is in Hosteurope.de, so i can switch between different php versions, however only 7.1 and 7.2 are available. version 7.0 got removed sometime in early December.
Edit: even this last command you mentioned doesn’t work. This is what i get.
sudo: vendor/oxid-esales/oxideshop-doctrine-migration-wrapper/bin/oe-eshop-db_migrate: command not found
Can’t help with this one, maybe a permissions issue, check if the script has execute permissions. PHP version should be checked because the cli version in the shell is sometimes different than the cgi version that you can choose for the webserver.
No migrations to execute indicates that all migrations already have been executed. While this is usually a good thing, i suppose this should not happen in case you make an update from 4.10 to 6 and you have not yet run migrations, because if you migrated the database, table “oxmigrations_ce” should contain only 2 entries.
Migrations are placed in /source/application/migration/data when you install or update the shop. There should be 6 files in there (Oxid 6.1.1). Now when you run the migrations command, the shop looks in the database table “oxmigrations_ce” if they already have been executed. If not, they are executed and the version is added to the “oxmigrations_ce” table. Next time you run migrations you get “No migrations to execute”.
And now you can check wether these exist in table oxmigrations_ce. If they do, migrations have either already been executed or the table was not deleted before importing the 4.10 database during the update.
Yes sure, just delete all tables and views and do step 2-4 again (and step 5 in case you didn’t copy the images yet). Don’t forget to deactivate the modules in the 4.10 shop, might be difficult to do this later, then import the 4.10 database into the now empty 6.1 database.
