Is_resource() returns false for Curl Handler when crawling url

WP Static Site Generators WP2Static
#1

Hello everyone!
I stumbled in a weird issue…

within the file Crawler.php there is the function crawlUrl() and at the beginning it retrieves the Curl Handler and it checks if it’s a resource. If it’s not a resource then it will bail out and won’t crawl anything.

Apparently that happens for all urls in my setup (Bitnami WP on AWS EC2 using php 8), but if I remove that check then the site is crawled and deployed correctly…

I am not sure what’s happening but if I log gettype($handle) it says it’s an object…
Could it have something to do with my setup? or maybe that conditional check should be less strict?

I am using version 7.1.6 of Wp2Static plugin.

thanks in advance for your help!

#2

Hi @andpicc,

Thanks for reporting the issue!

7.1.7 is latest release available. And there are even more fixes and improvements in the latest source code here: GitHub - WP2Static/wp2static: WordPress static site generator for security, performance and cost benefits

7.1.7 does note fixes for PHP 8 incompatibilities, so will need to try at least that version:

Please let me know if that sorts things out for you.

Cheers,

Leon

#3

Hello Leon! Thanks for your prompt reply!

I use composer to pull the plugins and I noticed it should’ve pulled the latest version already. So I tried to specify version 7.1.7 and I got an error from the security-advisories package…

Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - leonstafford/wp2static 7.1.7 conflicts with roave/security-advisories[dev-master].
    - leonstafford/wp2static 7.1.7 conflicts with roave/security-advisories[dev-master].
    - Installation request for leonstafford/wp2static ^7.1.7 -> satisfiable by leonstafford/wp2static[7.1.7].
    - Installation request for roave/security-advisories dev-master -> satisfiable by roave/security-advisories[dev-master].

do you think this could be caused by something wrong on my side? Or does it mean that something is triggering the advisor to block the installation?

#4

Hmm, interesting, I haven’t pulled for a while, so haven’t noticed that. It could be a warning, as the repo changed from leonstafford/wp2static to wp2static/wp2static. GitHub auto-redirects this so commands work, but maybe it’s causing some issues somewhere else…

If you can ignore the warning somehow, it should be fine (WP2Static architecture and non-public dev server typical setup usually mitigates common security issues).

Else, maybe can download a zip from GitHub for now.

I haven’t heard other reports about the issue yet, so maybe something environmental specific for you (newer Composer version, etc)

#5

Hello Leon, sorry for the delay but I have been dragged in other things and then I had to tweak some stuff in the server before testing any further.

With version 7.1.7 the crawling works and I manged to generate the static site!

though something weird happened with composer when I pulled version 7.1.7…

I’ve removed the security advisor package and so then composer pulled wp2static 7.1.7 but it was crashing when trying to run the crawling with this error:
PHP Fatal error: Uncaught Error: Class “GuzzleHttp\Promise\RejectedPromise” not found

I noticed that when it pulled the new version it also removed some guzzle packages and it added some other similarly named packages in vendor/leonstafford/

So then I tried to pull version 7.1.6 again and it reverted the dependencies too.
At that point I have removed wp2static from composer and manually uploaded the plugin version 7.1.7 (as downloaded from the repo) and I ran composer install into the plugin folder.
Then the plugin worked correctly and I was able to crawl and deploy the static site.

For now I have downloaded the zip installer and uploaded to the server manually (and that worked too), but would be better if I could use composer to pull your plugin along with the others. Any idea why this glitch could be happening?

thanks for your help!

#6

Hi @andpicc,

No worries re delay, I have some very slow response times myself here of late!

What I’d do with Composer here, is to start fresh - are you cloning/composer installing into same directory which had existing files? If so, you may try to delete the vendor dir and the composer.lock file or the whole plugin directory and try fresh.

I can’t recall which version it was introduced, but to avoid Guzzle conflicts, when different plugins use conflicting versions and the user isn’t using Composer, ie people installing plugins from WP admin, I made my own namespaced version of Guzzle and a few of its dependencies, we can see those in wp2static/composer.json at develop · WP2Static/wp2static · GitHub

I’m still not 100% sure what’s going on in your environment without some more digging/testing here, which I should set expectation is unlikely to happen in the next week.

So, am keen to hear any progress/further info from your side in meantime.

It will definitely be solvable, just unsure yet on which side we need to make some changes :smiley:

Cheers,

Leon