Skip to content
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

Open
drdogbot7 opened this issue Apr 27, 2021 · 2 comments
Open

html_type is overwritten when local wordpress_path is '/html' #616

drdogbot7 opened this issue Apr 27, 2021 · 2 comments
Assignees
Labels

Comments

@drdogbot7
Copy link

drdogbot7 commented Apr 27, 2021

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".

image

This changes the content_type that Wordpress sends to the browser in the response headers:

image

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

local:
  wordpress_path: /html

staging:
  wordpress_path: /var/www/html

Environment:
welaika/docker-wordmove
wordmove 5.0.2
ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-linux]

@alessandro-fazzi alessandro-fazzi self-assigned this Dec 26, 2021
alessandro-fazzi added a commit that referenced this issue Dec 30, 2021
It's worth to note that we're fixing this problem
with the cost of slowing down the operation.

For me it's solid and it's an acceptable tradeoff,
but on large databases this could visibly decrease
the overall procedure execution speed
alessandro-fazzi added a commit that referenced this issue Dec 30, 2021
It's worth to note that we're fixing this problem
with the cost of slowing down the operation.

For me it's solid and it's an acceptable tradeoff,
but on large databases this could visibly decrease
the overall procedure execution speed
@alessandro-fazzi
Copy link
Member

In 6.0 database string transformation will be done using a regex like

from \A/html\Z -> to /whatever/the/path

meaning that only the whole word /html will be considered.

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.

@stale
Copy link

stale bot commented Apr 16, 2022

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.

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

No branches or pull requests

2 participants