You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
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
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: