Xrow Gis Bundle Laravel Package

Getting Started

Read the description literally before anything else: this is not a Laravel package. It is a Symfony 2 bundle targeting eZ Publish 5.x (the legacy-bridge era), and its entire job is to make xrow's custom XrowGis legacy datatype — an eZ4 content attribute storing geographic coordinates — load and behave inside an eZ5 install. Zero stars, zero dependents, last release 2016-08-04. It is a museum piece, not a dependency you adopt.

• If you're on Laravel: there is nothing to install. composer require xrow/xrow-gis-bundle will pull ezsystems/ezpublish-kernel (~5.x), the legacy installer, and Symfony 2 constraints that collide with any current Laravel app. Treat the repo as reference material only.
• First place to look: the repo's composer.json (which eZ/Symfony versions it actually targets), then the bundled legacy extension. The real product is three files under extension/xrowgis/datatypes/xrowgis/ — typically datatype.php, ezxrowgistype.php (extends eZDataType), and ezxrowgis.php (extends eZPersistentObject). The Symfony bundle half is a thin wrapper that registers/autoloads those into the legacy bridge.
• First real use case: you maintain an eZ4 site with XrowGis attributes, you're moving to eZ Publish 5, and without this registration the datatype string no longer resolves — class editing breaks and templates render empty. That is the only scenario this package serves.
• If you're greenfield in Laravel, stop here and jump to the equivalent: two decimal columns (or a MySQL POINT SRID 4326 with grimzy/laravel-mysql-spatial) plus a Leaflet/clickbar/laravel-maps input. Everything below is either maintenance archaeology or a pattern to translate.

Implementation Patterns

You don't call this bundle in PHP — you activate it. Two registrations, both mandatory:

// ezpublish/EzPublishKernel.php
$bundles = [ /* ... */ new Xrow\GisBundle\XrowGisBundle(), ];

; ezpublish_legacy/ezpublish/settings/override/site.ini.append.php
[ExtensionSettings]
ActiveExtensions[]=xrowgis

The legacy extension must physically live under ezpublish_legacy/extension/xrowgis/. Clear both caches after any change (see Gotchas).

Reading the value in eZ5 templates. ez_field_value(content, 'location') returns an eZContentObjectAttribute; you then drill through ->content() and its accessors (lat/lng, sometimes a serialized blob). The pattern worth building is a small Twig extension or template operator that owns that drilling, so templates say {{ ez_gis_map(content, 'location') }} instead of spelunking attribute internals. This is the one extension point in the package with lasting value.

Querying by proximity is the weak spot. The datatype's persistent object is a custom table keyed on contentobject_attribute_id/version, so radius queries mean raw SQL joins. The pragmatic pattern on legacy installs: mirror lat/lng into a normalized column you control at publish time (ezpublish content events / onPublish) and do the geo query there. Do not expect the custom table to be indexed usefully.

The Laravel translation of the pattern — this is the actual takeaway for a Laravel dev:

protected $casts = ['location' => Point::class];

public function scopeWithinKm($q, float $lat, float $lng, float $km) {
    return $q->whereRaw('ST_Distance_Sphere(location, POINT(?, ?)) <= ?', [$lng, $lat, $km * 1000]);
}

Pair it with a FormRequest validating lat ∈ [-90,90] / lng ∈ [-180,180] and a map widget for input.

Migration pattern (eZ → Laravel). Export the contentobject_attribute rows for the XrowGis attribute, decode the datatype content (verify first whether it stores PHP-serialized data or a row in its own table — the two require different extraction), map to lat/lng, and import into your spatial column. Keep the original payload in a JSON column during cutover so you can diff.

Gotchas and Tips

• The bundle will not install in a modern app. Symfony 2 + ezpublish-kernel 5.x constraints, PHP 5.6/7.0-era syntax. Expect an unresolvable dependency graph, not a helpful error.
• Dead end upstream. No tests, no docs worth the name, no releases since 2016, and the underlying eZDataType API was deprecated in eZ Platform 2.x and removed in 3.x. The new (2015+) admin UI never supported legacy datatypes — editing only works in the legacy admin. Assume you are the maintainer the moment you install it.
• "Unknown datatype string XrowGis" at class-edit time almost always means one of: extension not under ezpublish_legacy/extension/, missing ActiveExtensions[], or a stale cache. Clear both layers — php ezpublish/console cache:clear and php ezpublish_legacy/bin/php/ezcache.php --clear-all --purge.
• Datatype ID mismatch is silent and destructive. The 'id' returned from datatype.php must match ezcontentclass_attribute.data_type_string exactly, or existing content stops resolving with no error at the DB level. Check this before and after any rename.
• Search/indexing. Custom datatypes need indexer support for field search; assume Solr/eZ Find has none here. Plan on legacy search or post-filtering, and don't promise a "search by location" feature on this stack.
• Versioning bites. eZ keeps one attribute row per version; proximity/display queries that forget the published-status/version filters return duplicates or pre-publish drafts. A classic bug in hand-rolled queries against ezcontentobject_attribute.
• Validation lives in the datatype. validateObjectAttributeHTTPInput (and the class-attribute equivalent) is where you enforce lat/lng ranges — there's no schema-level guard. If users can post garbage coordinates, that's the hook to tighten.
• If you must keep it running: pin PHP ≤ 7.x, vendor the legacy extension directly into your repo via a Composer path repository, commit the lock file, and freeze the stack. Don't count on upstream fixes for anything.
• The genuinely reusable extension points are a Twig function for coordinate formatting, a template operator for map rendering, and a publish-time hook to denormalize coordinates into a queryable column — all of which you'd rebuild natively in Laravel rather than port.