Xrowregexpline Bundle Laravel Package

Getting Started

1. Install via Composer — add the bundle to your eZ Publish 5 project:

   composer require xrow/xrowregexpline-bundle
   

   The package is a Symfony bundle that ships a legacy extension for the Regexpline datatype (a single-line text attribute validated against a regex pattern), so the install must be followed by a legacy-extension registration step.

2. Register the Symfony bundle in ezpublish/EzPublishKernel.php (or app/AppKernel.php in the Symfony 2.x variants):

   $bundles = array(
       // ...
       new Xrow\RegexplineBundle\XrowRegexplineBundle(),
   );
   

3. Register the legacy extension in ezpublish/config/ezpublish.yml (or ezpublish.yml) under the legacy settings so the eZ Publish 4-era datatype code is loaded:

   ezpublish:
       legacy:
           extensions:
               xrowregexpline: true
   

   Alternatively add ActiveExtensions[]=xrowregexpline in settings/override/site.ini.append.php if you are bootstrapping the legacy kernel directly.

4. Look first at these files (in this order):

   • Resources/config/ — services and any DI wiring.
   • eZ/Publish/Extension/ or extension/xrowregexpline/ — the actual datatype PHP (xrowregexplinedatatype.php), its datatype.php, content.php, and view handlers.
   • Resources/views/ or design/standard/ — the edit/view templates that render the input field. These three places tell you the whole lifecycle: definition, storage, and rendering.

5. First use case — create a content class attribute of type Regexpline in the eZ admin (Content → Classes → Edit), supply the regex pattern in the attribute settings, and publish an object through it to confirm validation fires in both the legacy admin and the Symfony frontend.

Implementation Patterns

• Datatype-as-attribute pattern. Regexpline is used exactly like a TextLine: add it to a content class, then read it in templates with attribute.content (or attribute.value depending on the bundle's content.php). The regex lives in the content class attribute definition, not in the object, so it is a per-attribute rule.

• Validation on the write path. The intended integration point is the datatype's validateObjectAttributeHTTPInput() / fetchObjectAttributeHTTPInput() methods. If you need extra validation (e.g. uniqueness or cross-field checks), extend the datatype rather than adding a Symfony form constraint — the admin UI bypasses Symfony's form layer.

• Frontend rendering. In eZ legacy view templates:

  {attribute_view_gui attribute=$node.data_map.my_regex_field}
  

  Make sure the bundle's design/standard/templates/content/datatype/view/ezstring.tpl equivalent is overridden in your design so the value (and any error message) is styled consistently.

• Symfony controller access. Read the attribute through the public API:

  $content = $contentService->loadContent($contentId);
  $value = $content->getFieldValue('my_regex_field')->text;
  

  Symfony-side validation is not enforced automatically — replicate the regex with a Regex constraint if you accept writes from a Symfony form.

• Content class seeding. If you provision environments programmatically, define the Regexpline attribute via the eZ content-class API and store the regex in the datatype's data_text / settings array. Keep the regex in version control as part of your fixture (.yml / JSON), because it lives in the class definition, not in code.

• Multi-site / multi-design. Register the legacy extension per siteaccess if you run several; the datatype must be active for the admin siteaccess and the frontend siteaccess that consumes the class, otherwise the field renders blank.

Gotchas and Tips

• Status and maintenance. Last release 2016-10-21, 0 stars, no dependents. Treat this as unmaintained legacy glue code. Pin the exact commit/version in composer.json and vendor it into your repo if you can; do not expect upstream fixes.

• Legacy/symfony boundary. The bundle only "fixes" the Regexpline datatype so it works again under eZ 5's legacy bridge. The real logic is legacy PHP, not PSR-compliant services — don't try to inject Symfony services into the datatype. Pass data via static config or the legacy registry.

• Autoloading. The extension folder must be on the legacy autoload path. If the field type does not appear in the admin class editor, it is almost always because ActiveExtensions[] / the legacy extensions list did not pick up xrowregexpline. Check var/log/ezpublish*.log and run php ezpublish/console ezpublish:legacy:script bin/php/ezpgenerateautoloads.php if available.

• Regex escaping is the #1 bug source. The pattern is stored in the class attribute settings and often passed through XML/INI serialisation. Backslashes and anchors (^, $, \d, \/) get mangled. Test a pattern with delimiters and escaping end-to-end in the admin UI, then re-read the stored class to confirm the pattern survived round-trip. Prefer a pattern without a leading/trailing delimiter and let the datatype's preg_match add them, or vice versa — be consistent.

• Validation message customisation. Error text is usually a translation key in the datatype's content.php. Override the translation in your own translations/ or design/ override rather than editing vendor files.

• Empty vs. required. Like most eZ text datatypes, "required" is a class-level check on top of the datatype. Combine the Regexpline pattern with is_required in the class definition; the datatype alone typically does not enforce non-empty.

• Debugging checklist when a value fails to save or render:

  1. Is the extension active for this siteaccess?
  2. Does the class attribute show a regex in the class editor after reload?
  3. error_log() inside validateObjectAttributeHTTPInput() to confirm the hook is reached.
  4. Check ezpublish/logs/ and var/log/ for Undefined index / preg_match notices — the code predates strict PHP 7 typing.

• Extension point. If you need richer behaviour (e.g. server-side normalisation, cross-field rules), the cleanest path is a small custom datatype that extends the Regexpline datatype and overrides the fetch/validate hooks — not a subclass of the Symfony bundle, which has no meaningful service surface to extend.

• PHP version ceiling. Written for the PHP 5.4–5.6 era of eZ 5. Migrating to PHP 7/8 or eZ Platform (v2+) will require replacing the datatype with an eZ Platform FieldType (a proper Symfony service implementing FieldType + FieldTypeService). Do not assume this bundle survives that jump — plan a rewrite rather than a patch.