Not possible to force other wget directory

[djixas]

Hi, as you may know, CentOS has older wget which makes openmagelts script not compatible

I've installed wget as separate bin, but it seems there is no way to "force' a different path for script?

$ curl -fsSL https://migrate.openmage.org | sh

> _Detected that you have installed Magento Commuinity Edition 1.9.4.5
> Downloading patch for Magento CE 1.9.4.5 to OpenMage LTS v19.4.8...
> wget: unrecognized option '--no-hsts'
> Usage: wget [OPTION]... [URL]...
> 
> Try `wget --help' for more options._

I do have newer weget installed at ~]# /bin/wget-1.21 though, wondering how to force it if possible?

[djixas]

I've now tried using user shell which gives correct wget version, aka latest, but this script still for some reason goes with server and not user version

[xx@host ~/public_html]# wget --version
GNU Wget 1.21 built on linux-gnu.

curl -fsSL https://migrate.openmage.org | sh

[addison74]

The code of the migration script has not been brushed for a long time. Like you there are a few who have reported problems in the last two years. Why do you necessarily want to use it when you have a simpler method at hand? Make a complete backup of the files and the database, then delete all the files that belonged to Magento only, at one point I found a script that ran and deleted the files of a certain version. Only your changes in files and directories will remain. The last step is to copy the latest version of OpenMage 19 or 20 into the directory. Activate the logs and check the Frontend/Backend intensively.

[djixas]

The code of the migration script has not been brushed for a long time. Like you there are a few who have reported problems in the last two years. Why do you necessarily want to use it when you have a simpler method at hand? Make a complete backup of the files and the database, then delete all the files that belonged to Magento only, at one point I found a script that ran and deleted the files of a certain version. Only your changes in files and directories will remain. The last step is to copy the latest version of OpenMage 19 or 20 into the directory. Activate the logs and check the Frontend/Backend intensively.

A simpler method than just typing one line of code, which is deleting files, looking for certain versions, copying latest versions, and doing other things.

Your "simpler" definition is an interesting one, and if this migration script so outdated, they should NOT advertise it on site

[addison74]

I understand that you didn't like my answer but I told you what I would do if I were in your place. It is not a matter of time. Rather than running a script that makes changes in tens of thousands of files it's better to personally control the entire process and make sure that I have all the files in line with the latest version.

Regarding the non-updating of the script, I cannot say anything. I doubt that you will find people interested in checking in a CentOS which would be the source of the issue.

[colinmollenhour]

What harm would come from copying the new binary over the old one?

[addison74]

If he wants to slap the contents of the archive on top of what already exists it would be good to check if he hasn't made changes in the Magento base files over time. I know that through all the posts of the time it was obsessively suggested not to modify the installation files, but I encountered this situation because of this and I am looking for all the files modified later that should not be edited.

When he installs packages with Composer as we already impose in OM 20, he should clean Magento installation first. Let's not forget we moved some to other places, others we deleted. Orphan files would remain, or my method eliminates this situation as well. Also, if he modified files and put them in /app/code/local, he must correlate them with the ones he adds because problems could arise.

[colinmollenhour]

@addison74 Yeah we haven't maintained this script or the set of patches it uses so at the moment it would be installing a fairly old version.. With all of the major refactoring that has been done I'm not sure this script is worth maintaining.. Probably the diff/patch files would need to contain the entire vendor/ directory.

Should this script be deleted then to discourage further use, or updated to include files added by "composer install" and automated to generate patch files for each new release?

[addison74]

Your proposal is welcome. I am in favor of closing this repository, but I would also like to hear the opinion of others.

[djixas]

@addison74

The script works with my workaround, which is easy to explain in script readme, so I would put it on archive for some people to download still.

As for doing the other way, I have 5 magento stores on 1.9, so doing one by one is a nightmare without automation, still, everything works after a single line of code and creation of htaccess files from default magento dir + dropping htaccesss.sample. Hopefully, this is useful to someone.

[addison74]

@djixas - Please read carefully what the person who created and maintained this script says above, a person with a lot of experience. Important changes have been made to the OpenMage code in the last year. The fact that the script is running is not a guarantee that everything will be as we expect it to be. It definitely needs to be updated, but I am not the right person to decide if it worth the effort or not.

[fballiano]

@addison74 I also think this repo should be closed.

[addison74]

I agree but let's wait for @colinmollenhour's final opinion. He is the one who maintained this repo. At this moment anyone can update/upgrade using a better option like Composer.