Module TextformatterImageLinkInterceptor

[rot]

I had the common css problem of not beeing able to format a link by its children.

Thus I ended up producing a very simple Textformater:

TextformatterImageLinkInterceptor

Processwire Image Link Interceptor Module

@copyright 2015, Roman Seidl
based on HTML Image Interceptor Textformatter @copyright 2013, Martijn Geerts
Licensed under GNU/GPL v2, see LICENSE.TXT

This module simply adds a class to all images that ae contained in a link as the first child.

Thus the following:

  <a href="/">
    <img src="/site/assets/files/1/hansi.jpg" alt="Hansi">
  </a>

Should be filtered to be:
 

  <a class="imglink" href="/">
    <img src="/site/assets/files/1/hansi.jpg" alt="Hansi">
  </a>

Github: https://github.com/romanseidl/TextformatterImageLinkInterceptor/blob/master/README.md

Changelog

• 0.1.1 Changed the directory layout to conform with Processwire module standards. To do so, the github repository had to be  renamed.

Edited April 18, 2015 by Nico Knoll
Added the "module" tag and removed it from title.

[adrian]

Hi rot - thanks for this.

Might I make a small suggestion. You might find it simpler to use DomDocument - something like this:

$p = $pages->get(1);

$dom = new DOMDocument();
@$dom->loadHTML( mb_convert_encoding($p->body, 'HTML-ENTITIES', "UTF-8") );
$dom->preserveWhiteSpace = false;

$images = $dom->getElementsByTagName('img');

foreach ($images as $image) {

    // the existing classes already on the images
    $existing_classes = $image->getAttribute('class');

    // the class we're adding
    $new_class = ' this-will-be-the-class';

    // the existing classes plus the new class
    $class_names_to_add = $existing_classes . $new_class;

    // add class to the parent of the img node - <a>
    $image->parentNode->setAttribute('class', $class_names_to_add);
}

In this example I am applying it to the body field of the homepage, but you get the idea

[rot]

Hi rot - thanks for this.

Might I make a small suggestion. You might find it simpler to use DomDocument - something like this:

Thanks for your comment!

I considered that but I discarded it because i think that using DOM might add unneccesary overhead to a very simple filter. I don't know if this is the case but I suppose using regexp scales better.

If anybody thinks this is not the case please let me know.

P.S.: I don't know if you remember the good old SAX vs. DOM disccussions? Haven't seen any within the last years but they were very common at least within the java-xml community

[adrian]

I have always read that DOMDocument was much quicker than regexes for parsing HTML, and it's certainly easier to build and read. Sounds like you know what you're doing though - sorry if I came across too strong - hard to know someone's experience level initially.

Anyway, keep up the good work!

[rot]

I have always read that DOMDocument was much quicker than regexes for parsing HTML, and it's certainly easier to build and read. Sounds like you know what you're doing though - sorry if I came across too strong - hard to know someone's experience level initially.

Anyway, keep up the good work!

This could easily be the case. I think that DOM adds a memory overhead but it might be faster especially with more complicated searches.

Hard to tell which choice is better with this. I sticked with Martijn Geerts' example and my slight preference for low memory usage over possible speed.

[rot]

I changed the directory layout to conform with Processwire module standards. To do so, the github repository had to be renamed. The version number was increased to 0.11

BTW: I asked myself if one should extend this module to allow for arbitrary class additions to parent elements. If there is the need for another selector that adds a class to an element based on the existence of a sub-element I could change the class to allow for that.