-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
html_type is overwritten when local wordpress_path is '/html' #616
Comments
In 6.0 database string transformation will be done using a regex like from meaning that only the whole word This will be A LOT slower on huge databases, but correctness of execution is absolutely more important. Thank you for taking the time to open the detailed report. And please, do not use the alpha version containing the fix against production or important installation. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Describe the bug
When the local wordpress_path is set to '/html' this causes a database push to change the 'html_type', replacing '/html' with the remote_path.
For instance if the remote path is "/var/www/html" the "html_type" will change from "text/html" to "text/var/www/html".
This changes the content_type that Wordpress sends to the browser in the response headers:
Since this is an invalid content type, the browser will default to displaying the page as plain text (chrome) or prompting the user to download a file (Firefox).
welaika/docker-wordmove uses '/html' as the default working directory, so it is probably not uncommon for this to happen.
Wordmove command
wordmove push -d
Presumably the same issue would affect the
pull
command if the remote path was '/html'Expected behavior
wordmove should NOT change "html_type" in the "wp_options" table.
movefile.yml
Environment:
welaika/docker-wordmove
wordmove 5.0.2
ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-linux]
The text was updated successfully, but these errors were encountered: