image_captcha requires php:^8 since update, breaking existing php:<8 installations

Hi corE, thanks. Yes, image_captcha module was moved into the "modules" folder in version 2.x that was backported yesterday.
It should be enough to rebuild caches. Did you try drush cr?

PS did you use composer + drush for the update or Drupal Update UI + update.php?

made changes in image captcha.info.yml file successfully.

Thanks @Shreya_98, I relabeled the title. image_captcha won't work with PHP <8, so the best you can do is to revert the .info.yml change and upgrade to at least PHP 8.0 - which would also make a lot of sense for security reasons, as PHP 7.x is EOL.

If we want to fix this, we'd have to add the same PHP requirement to captcha.info.yml and especially composer.json so that the version with this submodule php requirement is never chosen by composer on systems with php < 8.

Still I think there are many many good reasons to just upgrade to PHP 8.

Anybody → closed merge request !74

Just had a look into 8.x-1.x and there's no such code. You're using 2.x! ;)

Anybody → closed merge request !75

Added a MR to require php:^8 in the master module and composer so that people using php <8 are not upgraded to 2.x and keep 8.x-1.x instead, until they are on PHP 8.

Clarification. Reason: Drupal and composer don't care for the limitation in the submodule.

Let's wait for feedback from @japerry and others. I think this is an edge-case, but probably worth fixing by the MR.

Since 8.x-1.x and 2.x are the same code, it'd be nice if these files didn't diverge. And since I don't see why we need to use PHP8 for imagecaptcha yet, I'd rather we remove the erroneous requirement from the sub module..

@japerry the reason for that was an unsupported function, if I remember correctly. I think @Grevil knows (tomorrow).

So be careful when just removing the requirement, but there might be a ways to make it compatible. I think it wasn't a big thing.

PS: Sorry for the confusion with 8.x vs. 2.x - I saw later that the 8.x releases are now based on the 2.x branch. I first thought you'd merge 2.x into 8.x-1.x but makes sense, you just have to know... ;)

Thank you @Anybody , in answer to you question I'm updating through the browser and admin update page. I put into maint mode and flush caches prior, but didn't flush them during or after drupal downloaded. I got the white screen prior to update.php and reinstalled the previous files (ftp). Just FYI if you still need / is helpful.

@Anybody

PS... I see that update 8.x-1.12 was released. I tried to update but got the same white screen result.

The website encountered an unexpected error. Please try again later.
AssertionError: The file specified by the given app root, relative path and file name (.../modules/captcha/image_captcha/image_captcha.info.yml) do not exist. in assert() (line 68 of core/lib/Drupal/Core/Extension/Extension.php).

This time I tried to clear the caches after the download and file replacement, but got another white screen. So I replaced captcha folder in modules with the last version that worked 8.x-1.10.

Not sure if I'm missing something here [scratching head]

@corE, did you delete the old module first via FTP, before you uploaded the new one? (you should)
Which PHP version are you using?

There could be a few issues causing this, which unfortunately I'm not sure how we capture in tests... As @anybody mentioned:
1) Ensure you have deleted the captcha module before downloading the new one. Composer does this automatically to ensure no 'zombie' code is left...
2) Clear any apcu or other caches, in addition to Drupal caches. I've seen odd things where people see these issues as well as 'Class not found', even after a cache clear. It then 'magically' fixes itself, indicating that there is a opcache, apc cache, or some other cache that is referencing the old files.
3) Worst case, uninstall the module and reinstall after making a backup of the config. Although, technically this can be problematic if those outside caches aren't cleared either.

Since you said you were running PHP8.1, it doesn't seem like this is related to PHP8 at all. I haven't tried it yet, but maybe there is a case where sub modules quietly won't install if they don't meet php requirement? I don't think thats the case here.. but in either case, If you're running php 8.1, its a moot point.

I have the same problem, which happened in the upgrades to .11 and .12. I have Drupal 9.5.10 and running PHP 8.0.28. So, it doesn't look like upgrading from PHP 7 -> 8 would make it go away. I tried the upgrade both via Drupal admin UI and composer, both failed.

@milan.durovic thanks for the report. Did you try
drush updb
drush cr

The reason behind this issue is, that the captcha_image submodule was moved into the "modules" directory as best practice, but a cache on your project still seems to tell Drupal the old path -.-
See #24

Hi Anybody,

Ok, I tried your suggestion. First, I did *updb* and *cr* BEFORE the upgrade, then performed the upgrade. This caused the crash exactly as before. Then I ran *updb* and *cr* AFTER the upgrade and the site got back to normal and is showing that CAPTCHA is upgraded.

Thanks for the tip. I'm not sure if these steps can be automated, ie. included in the upgrade. Perhaps it would be good to at least include them in release notes if it's not possible to automate it.

Thanks again for your prompt answers and help.

Regards,
Milan

Thanks for the feedback Milan and nice to hear you're back online!

Clearing the cache is already part of the update, but perhaps we have to do more or a complete cache flush (which I think is dangerous in updates). @japerry any ideas based on that feedback?

@Anybody

I just wanted to add my latest update results... I'm understanding this issue is still open and in work process.

I seem to be stuck on CAPTCHA 8.x-1.10 as the last version that will work. Today I tried updating to 8.x-1.13 and got the same white screen result \:

The website encountered an unexpected error. Please try again later.
AssertionError: The file specified by the given app root, relative path and file name (.../modules/captcha/image_captcha/image_captcha.info.yml) do not exist. in assert() (line 68 of core/lib/Drupal/Core/Extension/Extension.php).

I am updating through the Drupal admin update screen, putting in maintenance mode and clearing caches prior to download.

• Drupal Version 9.5.10
• PHP Version 8.1.21

After the download, and file replacement step, I get the white screen and am not allowed to clear that cache after that. So I don't proceed to update.php.

I even tried FTP file replacement to 2.0.4 and still got the same white screen message.

So I FTP file replaced back to the 8.x-1.10 version. I have been trying the released versions as they come out with the same results and having to roll back the files to 8.x-1.10.

So, I seem to be stuck on 8.x-1.10 for now.

I don't think there is anything wrong on my end, that I can detect. I was wondering if this is something I should just wait on for the fix, or if there was a patch I'm missing, or if I should just uninstall the module and reinstall to an updated version (probably 2.0.4)?

Please advise, Thank you - Eric

Hi corE.

I guess the reason is very specific case, but as you're using PHP >8, it doesn't fit this issue title anymore?

Like in #27 and as written in #24 I think the reason is a caching layer not being cleared and using the no more existing path in the module.

Just read you PS's:

PSS... I was reading through the threads and saw reference to opcache. I occasionally have to clear this in the file structures because old ones are not automatically deleted and I like to keep things tidy. I was wondering if this may be causing the problem?? Or even something in Drupal core?? [hum...scratching head]

Yes, very likely!

PS, or maybe clear the cache through the database??

You should try both!

Please let us know about the results. Sorry for the inconvenience, but I think that's not something we could fix on our end.
The message clearly shows that your system says a file is not existing, which is existing and was moved.

../modules/captcha/image_captcha/image_captcha.info.yml is definitely the old path. It moved into "modules" folder, as of Drupal best practices.

PS: This is still needs work as of #13. to remove the PHP 8 requirement, if possible.

Hi @Anybody

I just wanted to post what I tried here just for information if helpful.

The clearing of the various caches ( #30 🐛 image_captcha requires php:^8 since update, breaking existing php:<8 installations Fixed ) didn't work so I uninstalled the captcha and the 3 dependent modules I had (Image CAPTCHA, reCAPTCHA, Captcha Riddler). I deleted the captcha folder and ran update, cleared cache and opcache (repeat 3 times). I then installed the recommended version 2.0.4 and re-enabled everything (running updates and cache clearing) and set everything up like I had it. I was using Riddler as my default.

Everything seemed to be good until I logged out and tried to log back in. I got the login screen, with the captcha (riddler) and filled out as normal, but when I submitted I got a white screen again. I wish I could have collected information to give here, but I was locked out and couldn't.

I tried a number of things, mainly trying to disable via database → :

• DELETE FROM `key_value` WHERE name = 'riddler'
• DELETE FROM `key_value` WHERE name = 'recaptcha'
• DELETE FROM `key_value` WHERE name = 'image_captcha'
• DELETE FROM `key_value` WHERE name = 'captcha'

But it didn't work and the captcha challenge was still there, giving the white screen after submittal. Eventually I had to roll back the whole database to an earlier day and replace the captcha file to the last working version 8.x-1.10... so still stuck at 8.x-1.10.

Now I'm afraid of the module to be honest.

I was having another white screen issue with the visitors module. bluegeek9 🐛 The website encountered an unexpected error. Please try again later. Fixed mentioned "I was able to fix the white screen of death issue with a try/catch." I have no idea what that means, and I don't know if the issues share a similar problem, but I thought I'd mention it here because... who knows... I'm so tired and stressed I don't know what I'm thinking. Throwing spaghetti at the walls here I guess.

Anyway, I think I going to rest and set this down for a while and use the 8.x-1.10 for a while.

Remaining hopeful.

Hello,

I have the same issue as corE.
I am updating through composer and get the same error when I try to open the site before an updatecycle has occured because I have no drush and do the update from within the user interface.
I then was trying to run an update.php but couldn't because I wasn't logged in as an administrator. I had to edit the settings.php file and set $settings['update_free_access'] to TRUE before I could do an update.php.
After the update of the module, I've restored the setiing in settings.php and then I could login as an administrator and everything went fine.
Maybe this is a tip for corE to get things running again.
Greetings

Seems to be related to a core issue... 🐛 Moving modules breaks system Active -- unfortunately there isn't a way to go back to the old path... without breaking people's current setup.

Thanks all, I think we should get back to the original issue and remove the PHP8 requirement from image_captcha as of #13

All other reports of broken installations are unrelated to the PHP version, but can typically be solved by running update.php / drush updb and clearing caches, see comments above.

Thank you @EricVL

I'm sorry you had problems but... misery loves company and I'm glad I'm not the only one.

After my un-installation process I did manage to get version 2.0.4 installed, and it seemed to be going fine, but when I logged out, and tried to log back in, captcha gave me a white screen after hitting submit button. I had Riddler as my default so I'm not sure if that had anything to do with it. I couldn't get any log information because I was logged out. I'll stick a pin in you settings.php workaround if I try to do this again. I just don't have the time.

I was really disappointed that disabling modules in phpMyAdmin → didn't work. The newer MySQL is different from the old, where you just changed a 1 or 0 value is status. Now it seem you have to upload and replace a blob entry key_value-value.bin ?? Maybe I didn't catch the right blob fish, my entry said i:8907; which I don't understand. I'll have to research this to find the right way. I recall doing this a while back and found a 1 and 0 entry for a module, but it required uploading/replacing a file as opposed to the old way of just changing a value.

Anyway, the database replacement worked well and was quick, so I'm going to be a stickler about backups before updating stuff.

I hope this can be ironed out or else I'll probably just have to stick with this version as log as I can, or find another solution.

@japerry, if I understood you correctly in our Slack conversation, there is no need to bring back "imagedestroy()" for the PHP < 8 support? Or should we simply readd it just to be sure? (Since it has NOP for PHP 8+). See #3312639: [2.x] Drupal 10 only / PHP 8: Function imagedestroy() is removed. → , this was the original reason image_captcha has the PHP 8 minimum requirement.

I was previously mistaken -- imagedestroy should be brought back so we can properly support PHP 7. There aren't any plans currently to remove imagedestroy() from PHP, its just been made NOP.

However, we should ensure 'unset' is added after imagedestroy to make sure we're not wasting resources. See https://php.watch/versions/8.0/gdimage

Alright!

All done! Please ignore "Remove duplicate 'file_format' assignment". This was already done upstream, and after rebasing leads to changing a comments ending character from ":" to ".".

Please review!

Thanks, I left some comments. Let's wait for @japerry's feedback.

All done! Please ignore "Remove duplicate 'file_format' assignment". This was already done upstream, and after rebasing leads to changing a comments ending character from ":" to ".".

Shouldn't this be reverted into ":" again then? Makes more sense to me here.

You are right, sorry! From the php unset() docs:

This is probably trivial but there is no error for unsetting a non-existing variable.

Good to know! Thanks :)

Fixed!

Automatically closed - issue fixed for 2 weeks with no activity.