Skip to content
This repository has been archived by the owner on Sep 1, 2023. It is now read-only.

magento script problem #4

Open
rr10 opened this issue Jan 3, 2021 · 11 comments
Open

magento script problem #4

rr10 opened this issue Jan 3, 2021 · 11 comments

Comments

@rr10
Copy link

rr10 commented Jan 3, 2021

php 7.2
cpanel
magento 1.9.4.3

I followed the guide below with method 1

https://www.openmage.org/magento-lts/migration-guide.html

but i've this error:

00102@srv8 public_html]$ curl -fsSL https://migrate.openmage.org | sh

| _ | | / | | | |_ / |
| | | | __ ___ _ __ | . . | __ _ __ _ ___ | | | | \ --. | | | | '_ \ / _ \ '_ \| |\/| |/ _ |/ |/ _ \ | | | | --.
\ _/ / |) | __/ | | | | | | (| | (| | __/ | || | /_/ /
_/| ./ ___|| |_| |/_,|_, |_| _/_/ _/
| | __/ |
|| |_/

This script will download the appropriate patch for your Magento installation
and update the core source code to OpenMage LTS v19.4.8.

DO NOT continue if you do not have an easily restorable backup!

DO NOT run this migration on production unless the result has been thoroughly
tested in a development environment for compatibility issues.

Migration will begin in 20 seconds. Press CTRL+C to abort.

Detected that you have installed Magento Commuinity Edition 1.9.4.3
Downloading patch for Magento CE 1.9.4.3 to OpenMage LTS v19.4.8...
wget: unrecognized option '--no-hsts'
Usage: wget [OPTION]... [URL]...

Try wget --help' for more options.
@colinmollenhour
Copy link
Member

Thanks for the report, it looks like your wget doesn't support the --no-hsts option.. Is it a particularly old version?

@cylkee
Copy link

cylkee commented Jan 20, 2021

I have this problem too. My wget version is 1.14 and there appears to be no update for my CentOS distro.

@cylkee
Copy link

cylkee commented Jan 20, 2021

I have instead saved a local copy of the script in the root of the installation, removing the --no-hsts option, ran source migrate.sh at the command prompt and then got a whole heap of "patch does not apply"...

error: patch failed: skin/install/default/default/css/reset.css:19
error: skin/install/default/default/css/reset.css: patch does not apply

My installation remains on 1.9.4.2.

Unable to apply the patch. The following command failed:

    git --git-dir=/dev/null apply --ignore-whitespace --check var/magento-ce-1.9.4.2-openmage-lts-v19.4.8.patch

@colinmollenhour
Copy link
Member

patch does not apply

Do you have core file edits?

@colinmollenhour
Copy link
Member

@gtsiou This seems to stem from the issue caused by the SSL cert being for *.s3.amazonaws.com but our subdomain having two parts so the browser does not consider the SSL cert to be valid.. Can we get a new bucket that has a hyphen instead of a dot in the name? Or perhaps a CNAME, @LeeSaferite?

@cylkee
Copy link

cylkee commented Jan 20, 2021

Do you have core file edits?

Uncertain. I have inherited this installation and I'm unfamiliar with Magento. Can you give a few examples of core files that are commonly edited and I will attempt to cross-reference with the output of the script. However, it looked like many hundreds of files that were reporting "patch failed" "patch does not apply"

@cylkee
Copy link

cylkee commented Jan 21, 2021

Scratch that. I've done a fresh installation of OpenMage 1.9.4.10 and connected the previous DB and copied over media, theme etc. Fingers crossed...

@toledoroy
Copy link

Having the same problem on CentOS 7 w/latest of yum's wget
Any fixes / workarounds?

@colinmollenhour
Copy link
Member

Hi @toledoroy if you are referring to the wget issue you can edit the script and remove the --no-hsts option and run your modified script.

@toledoroy
Copy link

Thanks @colinmollenhour

@gtsiou
Copy link
Collaborator

gtsiou commented Aug 17, 2021

@gtsiou This seems to stem from the issue caused by the SSL cert being for *.s3.amazonaws.com but our subdomain having two parts so the browser does not consider the SSL cert to be valid.. Can we get a new bucket that has a hyphen instead of a dot in the name? Or perhaps a CNAME, @LeeSaferite?

Is that still an issue? We can absolutely try with a different bucket but a CNAME would be ideal.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants