Can't import items with PHP 5.2 and MySQL 5.1

[miriamposner]

When I attempt to import items, I get the following message:

Warning: mysqli_stmt::bind_result() [mysqli-stmt.bind-result]: Server returned unknown type 255. Probably your client library is incompatible with the server version you use! in /home/miriampo/public_html/omeka/application/libraries/Zend/Db/Statement/Mysqli.php on line 255

Fatal error: Call to a member function out() on a non-object in /home/miriampo/public_html/omeka/plugins/Neatline/helpers/Coverage.php on line 26

When I remove all information from coverage fields, it appears to have imported my items, like so:

but no records actually show up in the exhibit.

Possibly relevant: I switched from background processing to synchronous processing because I don't have PHP-CLI on my server.

My system info:

Omeka 2.1.4
PHP 5.2.17 (cgi-fcgi)
OS Linux 2.6.18-371.6.1.el5 x86_64
MySQL Server 5.1.73
MySQL Client 5.1.73
PHP Extensions
Regular bcmath, bz2, calendar, cgi-fcgi, ctype, curl, date, dbase, dom, eAccelerator, ew, exif, ffmpeg, filter, ftp, gd, gettext, hash, htscanner, iconv, imap, ionCube Loader, json, libxml, mbstring, mcrypt, mhash, mime_magic, mysql, mysqli, openssl, pcre, PDO, pdo_mysql, pdo_sqlite, pgsql, posix, pspell, Reflection, session, SimpleXML, slog, snmp, soap, sockets, SPL, SQLite, standard, tidy, tokenizer, uploadprogress, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, Zend Optimizer, zip, zlib
Zend the ionCube PHP Loader, Zend Optimizer
Plugins
Coins 2.0.3
CsvImport 2.0.2
ExhibitBuilder 2.1.2
Neatline 2.2.4
SimplePages 2.1.1
Themes
Berlin 2.1.3
Omeka Foundation 2.0 (current)
Seasons 2.1.6
Thanks, Roy 2.1.1

[jeremyboggs]

Seems similar to #288. Not sure it's really an issue with PHP/MySQL versions.

[waynegraham]

This particular issue appears to be coming from the library we're using to parse the data. This appears to be the issue geoPHP library (https://github.com/phayes/geoPHP/blob/master/geoPHP.inc#L267-271). Basically if there is an entry that starts with the letters P, L, M, or G, GeoPHP attempts to read this as a WKT geometry.

So, if you have "Paris" in the coverage, this attempts to parse 'POINT(aris)' which fails since there aren't two parts to this string.

Instead of trying to patch the geoPHP library, let's wrap https://github.com/scholarslab/Neatline/blob/master/helpers/Coverage.php#L22 in a case statement that checks the full geometry object.

• Geometry
• Point, MultiPoint
• LineString, MultiLineString
• Polygon, MultiPolygon, Triangle
• CircularString
• Curve, MultiCurve, CompoundCurve
• CurvePolygon
• Surface, MultiSurface, PolyhedralSurface
• TIN
• GeometryCollection

[waynegraham]

After looking at the geoPHP library more, not all of the WKT types are supported. These appear to be the supported geometries:

• Point
• LineString
• Polygon
• Multipoint
• MultiLineString
• MultiPolygon
• GeometryCollection

[davidmcclure]

Or, if we're feeling lazy, we could also just try/catch line 26, where geoPHP tries to read the coverage.

[waynegraham]

That's not so much laziness as surrendering to someone else's poor implementation...

[davidmcclure]

Yep, probably easiest to just harden up NL for now. That said, I may try to squirrel away an hour at some point to fix this in geoPHP - it's a really useful piece of code, and I'm actually planning to use it for an unrelated project next month, so I'm happy to contribute back to it.