-
Notifications
You must be signed in to change notification settings - Fork 256
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
Crawling from WP CLI - Mangled URL - Uncaught InvalidArgumentException: Unable to parse URI #908
Comments
Logging this as an error rather than failing here |
The issue is, your site is configured for https, but some things are returning http urls, and wp2static doesn't respect that http and https should be respected as the same, so http://example.com != https://example.com and causes this error |
That makes sense I guess. I don't know where I would find the plugin that is the culprit, the thing is behind a reverse proxy so it all should be pointing to the ingress and never use unencrypted. How come it's bunged on the end of the URL though? From memory I thought I added some logging and that literal URL was what was trying to be parsed by Guzzler. |
Before creating an issue / filing a support request
Determining if it's an issue with Theme, Plugin, Environment or a bug in WP2Static
This is a difference in behaviour between the CLI and web interfaces to WP2Static. So, even if there are issues elsewhere, I believe this is most appropriate as a bug against WP2Static itself for the time being.
Describe the bug
So far, WP2Static has worked without a hitch. I have installed from a ZIP file and only ever processed form the web UI.
This site is hosted on a local machin in a contianer; after exporting, the static site is sent up into the cloud for live hosting. _In the settings, I set the "Deployment URL" to be simply
/
; this has allowed maximal flexibility with hosting downstream, where the static site can be viewed under multiple subdomains without any problems. The export process from the web UI works fine with this.I took some time today to have a play kicking off the process programmatically using the
wp
CLI tool. If I begin the export this way (wp wp2static crawl
), from the logs it fetches all the pages okay, and then after this, at some point it seems an invalid URL replacement is being performed - or in some other manner, a totally mangled URL comes out. Then, this is throwing an exception and I get a backtrace in the logs.If I then proceed to generate the export again from the web UI, I get a 500 message back from the browser same as this one
If I delete the plugin, and re-upload from a zip, to nuke my settings (can I do this a faster way, BTW?); go back and change my settings, then we are back to normal. Given the documentation seems to be a little out of date, it's possible I am not using the CLI tool properly. Ideally I'd like it to kick off a job with the exact same settings as currently configured in the UI; but perhaps I need to give it some more options. Otherwise, this seems to suggest that the CLI tool is missing or adding a step that mutates the state in the settings, and so then web-based calls are failing too.
To Reproduce
Steps to reproduce the behavior:
wp wp2static crawl
Environment (please complete the following information):
The website is behind a reverse-proxy using a self-signed certificate. The reverse proxy only serves TLS; it communicates with the WordPress unencrypted only. The instance is externally visible on a non-standard port.
Log files (please complete the following information):
The text was updated successfully, but these errors were encountered: