Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I decided to test linkchecker before deployment to see if did the job that I needed it to do, so I deployed it on a test version of the site running on my desktop (Windows XP) via XAMP.
I was disappointed to see an AJAX error during the initial scan for links. The error message gave no clue as to the cause of the problem.
I eventually diagnosed the fact that a call to valid_url() was failing to return when it was called with a very long and complex Google Maps URL.
However a test of the call in isolation does not show the error, it which point it occurred to me that XAMP uses some flavour of PHP 5.4 and the live site runs on PHP 5.3.nn. I installed linkchecker on my staging server and the module behaved flawlessly.
I'm reporting this as a minor issue so that when PHP 5.4 becomes more prevalent and if the unexplained AJAX problem rears its ugly head there will be some record of a possible cause.
I've attached a debug backtrace of the failing call to valid_url()
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | httpd-vhosts.conf_.txt | 1.65 KB | rtrubshaw |
| #4 | drupal7.example.com_.conf_.txt | 4.43 KB | rtrubshaw |
| valid_url_fail.txt | 29.1 KB | rtrubshaw |
Comments
Comment #1
hass CreditAttribution: hass commentedThats preg_match() behind and valid_url() should be used in many other situations, too. Do you have any nodes with PHP code? It's the most typical issue (duplicate function definitions).
Comment #2
rtrubshaw CreditAttribution: rtrubshaw commentedI added a series of debug log statements to the valid_url function and used intermediate variables to allow me to isolate the call(s) to preg_match() and the call is logged but the statement following the call to preg_match is never executed.
There is no redefinition of preg_match as far as I can tell and an identical set-up running under PHP 5.3.nn works without a problem (and continues to do so).
This only occurs when I run on my desktop test/development environment (XAMPP) which runs some flavour of 5.4.
I tried making an isolated the call to valid_url() but this didn't cause any problems on either version of PHP.
The only idea I have at present is that something similar is happening to the PHP interpreter as when the call-time pass-by-reference warning is issued. Once issued various random classes are then subject to cannot redeclare errors. (see http://help.getpantheon.com/pantheon/topics/fatal_error_require_once_can...). I.e. at some point further up the call chain some subtle bug in 5.4 is exercised that does not mainfest itself until the call to preg_match()
As I noted orginally I don't see this as a big problem, I was just noting it for future reference as it may be "fixed" in a later release of PHP 5.4 before Drupal becomes more prevalent on it.
Comment #3
hass CreditAttribution: hass commentedI'm myself not sure how fast 5.4 goes into linux distributions and at very latest than, we are running in a lot of possible troubles. I have totally no clue today if we are able to workaround somehow or if this may not a linkchecker bug or not.
I have installed XAMPP with PHP 5.4 two weeks ago, but was not able make it ready for testing/repro. If this is a PHP 5.4 bug we need to close the case as it's not a bug of linkchecker itself.
Comment #4
rtrubshaw CreditAttribution: rtrubshaw commentedIf it is any help I've attached some Apache configuration files for XAMPP that I've just used to get a bare-bones D7 test site running. (You'll need to remove the .txt extensions and any underlines.)
1st - A replacement for ...\xampp\apache\conf\extras\httpd-vhosts.conf
(this assumes the creation of a new directory in the extras directory called ...\extras\vhosts.d
2nd - A new configuration file drupal7.example.com.conf that lives in ...\extras\vhosts.d
The 2nd configuration files assumes that the website source lives in:
C:\xampp\vhosts\drupal7.example.com\www
(and hence that XAMPP has been installed in C:\xampp)
The main thing is the contents of .htaccess have been added to the .conf file and the directory access stuff has been updated to the Apache 2.4 standard.
You'll also need to add the following line(s) to:
C:\windows\system32\drivers\etc\hosts
--- Lines start ---
127.0.0.1 drupal7.example.com
127.0.0.1 drupal7
--- Lines end ---
You'll need to use notepad or notepad++ (make sure that there is no extension added when the file is saved)
Comment #5
hass CreditAttribution: hass commentedFor me Apache is just crashing and restarting if I enter
<a href="http://maps.google.co.uk/maps?f=q&source=embed&hl=en&geocode=&q=Sense+Cymru+T%C5%B7+Penderyn+26+High+St+Merthyr+Tydfil+CF47+8DP++&aq=&sll=51.531045,-0.117335&sspn=0.010746,0.01929&dirflg=w&ie=UTF8&hq=Sense+Cymru+T%C5%B7+Penderyn&hnear=26+High+St,+Merthyr+Tydfil+CF47,+United+Kingdom&t=m&ll=51.743413,-3.377845&spn=0.00465,0.014741&z=16" rel="nofollow">View larger map</a>into the body field and press save.Nothing is inside php logs.
Comment #6
hass CreditAttribution: hass commentedMaybe https://bugs.php.net/bug.php?id=61577
Comment #7
hass CreditAttribution: hass commentedComment #9
specky_rum CreditAttribution: specky_rum commentedCan we reopen this? I am seeing this error on PHP 5.4.20 on Windows 7. When the link checker runs Apache crashes before it finishes. Looks like exactly the same issue as reported.
Comment #10
hass CreditAttribution: hass commentedThis is a bug of apache or php and not this module.
Comment #11
webservant316 CreditAttribution: webservant316 commentedI am seeing a related error with...
linkchecker 7.x-1.2
PHP 5.4.37
Litespeed 6.7
Comment #12
hass CreditAttribution: hass commented@webservant316: You may better use a webserver that is supported by Drupal. Just a hint.