After upgrading from Debian GNU/Linux Sarge to Etch (including PHP5, and MySQL5), amazontools broke completely.

When previewing a node, the screen blanks and fills with the error

Fatal error: Call to undefined function curl_init() in /var/www/.../modules/amazontools/amazon.php5.inc on line 308

Regards, -asb

PS: Also, in this version still exist several previous bugs (e.g. no icons for ratings, when Drupal isn't installed in the server's root etc.)

Comments

asbdpl’s picture

With PHP5 on Debian "Etch", the Amazontools seem to be completely broken. On different sites, and with any operation, it crashes the Amazontools or even the whole site (als long as the defunct module is activated).

E.g.: amazon_import/manage: "Refresh Prices"

Fatal error: Call to undefined function curl_init() in /var/www/{site}/modules/amazontools/amazon.php5.inc on line 308

E.g.: amazon_import: "Search for {string}"

Fatal error: Call to undefined function curl_init() in /var/www/{site}/modules/amazontools/amazon.php5.inc on line 308

E.g.: node/add/amazon-node: "Preview"

Fatal error: Call to undefined function curl_init() in /var/www/{site}/modules/amazontools/amazon.php5.inc on line 308

On one of the sites, this seemed to be caused by a missing CURL, as the error indicated. As it seems, Debian is unable to handle upgrades from PHP4 (Sarge) to PHP5 (Sarge and Etch) smartly; when switching to PHP5, dependencies are not resolved but have to be reconstructed manually.

You need to compare what was installed on PHP4:

# dpkg -l "*php4*" | grep ^ii
ii  libapache-mod-php4  4.4.4-8+etch1  server-side, HTML-embedded scripting language (apache 1.3 module)
ii  php4                4.4.4-8+etch1  server-side, HTML-embedded scripting language (meta-package)
ii  php4-cgi            4.4.4-8+etch1  server-side, HTML-embedded scripting language (CGI binary)
ii  php4-cli            4.4.4-8+etch1  command-line interpreter for the php4 scripting language
ii  php4-common         4.4.4-8+etch1  Common files for packages built from the php4 source
ii  php4-curl           4.4.4-8+etch1  CURL module for php4
ii  php4-domxml         4.4.4-8+etch1  XMLv2 module for php4
ii  php4-gd             4.4.4-8+etch1  GD module for php4
ii  php4-imagick        0.9.11+1-4.1   ImageMagick module for php4
ii  php4-mcrypt         4.4.4-8+etch1  MCrypt module for php4
ii  php4-mysql          4.4.4-8+etch1  MySQL module for php4
ii  php4-pear           4.4.4-8+etch1  PHP Extension and Application Repository (transitional package)

...and reinstall the missing packages for PHP5:

# dpkg -l "*php5*" | grep ^ii
ii  libapache2-mod-php5 5.2.0-8+etch1  server-side, HTML-embedded scripting languag
ii  php5                5.2.0-8+etch1  server-side, HTML-embedded scripting languag
ii  php5-cli            5.2.0-8+etch1  command-line interpreter for the php5 script
ii  php5-common         5.2.0-8+etch1  Common files for packages built from the php
ii  php5-curl           5.2.0-8+etch1  CURL module for php5
ii  php5-gd             5.2.0-8+etch1  GD module for php5
ii  php5-imagick        0.9.11+1-4.1   ImageMagick module for php5
ii  php5-mcrypt         5.2.0-8+etch1  MCrypt module for php5
ii  php5-mysql          5.2.0-8+etch1  MySQL module for php5

Curl for PHP5 can be installed by the usual

aptitude install php5-curl

However, on the other site, Amazontools are still broken completely (e.g. not even showing values for "Total registered items" or "Total stale prices"). Obviously, there are othere errors left.

Regards, -asb

asbdpl’s picture

Status: Active » Closed (fixed)

In short: The problems seem to be caused by the upgrade from Debain "Sarge" to "Etch", which included the migration of MySQL from version 4.0 (Sarge) to 5.x (Etch); this included also a new handling of charset encoding in MySQL (Unicode), which required a database conversion (without conversion, every non Ascii character in Drupal - and ony in Drupal - was corrupted).

Depending on who you believe, either Drupal or Amazontools isn't really UTF-8 clean; a conversion of the database dump with "sed -r 's/latin1/utf8/g' dump.sql > dump_utf.sql" completely killed the amazontools, while the fallback to an unconverted dump eliminated most non-English characters and words, but restored at least most Umlauts and Amazontools' fuctionality (dumping the database with "mysqldump --default-character-set=latin1 --skip-set-charset", reimport with "mysql --default-character-set=utf8 --force").

I'm closing this bug report since the failure of Amazontools seems not to be the cause but merely the indication of a more fundamental problem.

Greetings, -asb