Allow to specify a target URI for a textimage file in the API

Hi @webservant316

the logic for path management and theme calls in 7.x-2.x is indeed pretty clumsy :(

If I understand correctly what you are trying to do, I'd suggest to checkout 7.x-3.0-beta1 instead.

Firstly, you'll have to create an Image Style named 'bannertitle', including the textimage effects you need. Have a look at the README.txt file.

Then you'd have two options (just example code on top of my mind, not tested):

Option 1 - use theme calls

Just call the theme to render the output with your text. You do not need to care about the path where the image is stored.

    echo theme(
      'textimage_style_image',
      array(
        'style_name' => 'bannertitle',
        'text'   => array('my text'),
      ),
    ));

    echo theme(
      'textimage_style_image',
      array(
        'style_name' => 'bannertitle',
        'text'   => array('my text - revised text'),
      ),
    ));

In fact, the images will be created as 'public://textimage/bannertitle/my text.png' and 'public://textimage/bannertitle/my text - revised text.png' . Or as 'private://...' if you choose to store the images in the private file system (it's an option on the Image Style edit form). The only exception is if your filename cannot be created 'cleanly' (e.g. if your text array contains very long text or special characters); in this case the file will be stored in a special directory and the filename consist of a md5 hash; but you don't have to care - Textimage manages that for you under the hood.

Option 2 - use API calls

You want to create textimages programmatically. There's a specific API for that: you create the textimages, get the URI where they reside, and you can render them with a call to theme('image', ...). The location of the image file follows the same logic as in previous option.

    $my_text_uri = TextimageImager::getImageUri(
      'bannertitle',
      NULL,
      array('my text')
    );

    $my_revised_text_uri = TextimageImager::getImageUri(
      'bannertitle',
      NULL,
      array('my text - revised text')
    );

    echo theme(
      'image',
      array(
        'path' => $my_text_uri,
      )
    );

    echo theme(
      'image',
      array(
        'path' => $my_revised_text_uri,
      )
    );

Hope it helps... feedback appreciated.

7.x-3.0-beta1 = WSOD

Strange. True this version is pretty new, but this is the first report of WSOD, while some issues already are about using the module, so someone has got it installed and working. Have you tried a clean install?

Does TextimageImager::getImageUri both create the image and return the uri?

Yes - it creates the image, and returns the URI to the image created.

However, is the image overwritten or a new image created?

A new image file is created, with the new text inside the new image. So you have two files, one with text A and one with text B, under the same 'public://textimage/bannertitle' directory. This helps with caching because if you need again an image with text A, it will pick the existing one instead of re-creating it.

If you do not want to cache the textimages, and accept that they get created on the fly, you can disable caching. There's a variable for that in the theme call, and an argument in getImageUri.

    $my_text_uri = TextimageImager::getImageUri(
      'bannertitle',
      NULL,
      array('my text'),
      $extension = 'png',
      $caching = FALSE
    );

non cached images are be stored in a different directory (private://textimage_store/uncached/{hash}.{extension}), and get removed upon each cron run. getImageUri will return the URI to the uncached image. From there, you can either display the image to the user as such, or programmatically copy that file to whatever directory structure/filename you need.

module is seems to be designed with the thought that you do the file management for unique text strings.

Yes that is correct: input is a) an image style and b) some variable text. Textimage makes sure that given (a) and (b), an image file with text in (b) is generated and cached for further access.

7.x-2.0 worked great for me. Except this function doesn't return a new image if the text changes...

Can't remember how 2.0 was exactly doing this, but definitely it had problems - see e.g. #1969774: when chaining presets, cached image considers only last preset value and #1936172: Fatal error: Call to a member function realpath() on a non-object.... I suppose that's because if you specify a filename for text A and then the same filename for text B, 2.0 will anyway see that a filename exists already and return the image for text A.

Thanks

array_replace_recursive() is a PHP function, available for PHP >= 5.3.0. Which version of PHP are you on? If below 5.3.0, I found an alternate implementation in stackoverflow, maybe we can include that as a patch in the module. It would be great if you could test and let me know.

My preference would be a simple API [...]

Hm. This would have serious implications on the caching mechanism, as we should store away the text currently represented in a image file - how would textimage know that the text has to be changed otherwise?
If your concern is about having 'loose' textimages on the file system, you can always put a call image_style_flush('bannertitle'); in a periodic job (i.e. cron). That would remove all the image files under public://textimage/bannertitle, and next time getImageUri is called a new image will be recreated.

1. I'm on 5.4, no access to 5.2. Can you just test, placing the code snippet indicated in #9 from stackoverflow into textimage.module? If that solves the issue I will include it in the main repo.

2. Option 4 - use the solution in #7, using getImageUri and disabling caching. Get the URI of the textimage, copy it to whatever path/filename, delete the file from where you copied.

Created spinoff #2134439: Installing on PHP < 5.3.0 results in WSOD errors for the WSOD issue related to usage of array_replace_recursive() .

Forget about #11.1, sorry.

It looks like I should have been using drupal_array_merge_deep() instead of array_replace_recursive(). Please watch out for #2134439: Installing on PHP < 5.3.0 results in WSOD errors, I'll post a patch there tomorrow.

Changed to feature request based on comment in #13.2

Here's a patch. It extends the getImageUri method with an additional argument, $target_uri, where you can specify the full URI where the image should be stored. The file just gets generated at the URI specified (note the URI shall be inclusive of the file extension, differently than in 2.0). If there is a file at $target_uri, it will be deleted and recreated with the specified $text.

Use like

   $my_textimage_uri = TextimageImager::getImageUri(
      'bannertitle',
      NULL,
      $text = array('my text'),
      $extension = 'png',
      $caching = FALSE,
      NULL,
      NULL,
      $target_uri = 'public://my_path/my_filename.png'
    );

$my_textimage_uri will be set to 'public://my_path/my_filename.png' upon return.

NOTE: there will be no caching of an image if you specify $target_uri. That's because, given a URI, we could overwrite that file with whatever $text.

... and the patch ...

Reviewing, most probably we do not need to explicitly delete the file, as the lower level imagexxx() functions called by the toolkit via image_toolkit_invoke('save', ...) will anyway replace a file if already existing. Shorter patch then...

Of course, see the tests, I have one that generates a file for an URI, and then another one with different text for the same URI - they are passing i.e. only one file is counted in the destination directory.

Patches are always against dev, but in this case beta1 is currently equal to dev. To cut short - my recommendation would be to test with dev.

Could you also provide feeedback to #2134439: Installing on PHP < 5.3.0 results in WSOD errors?

I'd like to go for a beta2 when these patches are confirmed - we shouldn't live with a release that ends in a WSOD or a fatal (see #2106417: Fatal error: Call to undefined function _color_pack()).

Thank you for your help here.

Sorry for that, looks like a PHP 5.2 issue again. Will post a new patch under #2134439: Installing on PHP < 5.3.0 results in WSOD errors soon.

OK, the patch in #2134439: Installing on PHP < 5.3.0 results in WSOD errors passes. Unfortunately, the patch in this issue is colliding with that, so it would need to be re-rolled. To do that, I need to commit #2134439: Installing on PHP < 5.3.0 results in WSOD errors first. Can you check if you can install and run the module with the patch there?

#29 - I was not expecting this to be functioning yet. Can you please test with the patch here, and the new dev that will be built after the commits today.

#28 - getImageUri() returns the URI where the image is saved, or NULL if it fails. So you can simply have

  if(!$returned_uri = TextimageImager::getImageUri(...)) {
    ... [actions on failure] ...
  }

Patch here is a reroll of #19 after #2134439: Installing on PHP < 5.3.0 results in WSOD errors was committed.

Cheers

Great! Glad it's working. So this means I have to reintroduce the explicit file deletion I removed in #19. I would like to understand why the file does not get overwritten, though. I will look into it tomorrow.

I investigated a bit, and modified the logic of buildImage(). We may have the case that multiple requests require to access the image file at URI at the same time, and if we delete the image before we start the generation process, some of them will fail and render no image. I know it's not your use case, but still we need to look for this. So, instead of explicitly deleting the file, we let it be overwritten by the image generation process when the image is ready. So we shouldn't have the temp blackout in this case.

NOTE - while testing, I noticed that the browser may be caching the image at URI, and use a local copy even if we are rebuilding the source. This patch does nothing to prevent that, just the server side of overwriting the image file.

Have a look at this, just in case. It's something to be probably done at the theme('image',...) level.

Great! Thanks, I will commit this then.

The file private://styles/bannertitle was not deleted, because it does not exist.

... it's a Drupal core issue, see #2079315: Image style editing leads to redundant watchdog entries.

everytime after I get things set up to my taste there has been an 'uncached' folder in the private folder

Yes. That folder is (also) storing the previews of the image shown in the Textimage text effect admin UI. It's an image itself, and has to go somewhere... :) All the files in that directory get removed upon each cron run, so you shoudn't worry about that.

The file private://textimage was not deleted, because it does not exist.

Strange. If you understand more when this happens, please open a new issue, let's close this one now.

Committed and pushed to dev.

Released 7.x-3.0-beta2

Is there any way to use tokens in order to retrieve the hashed target uri? The idea is to use the path of the image in OG meta tags.
I am using text image to create image quotes but i cannot figure any way in order to retrieve the actual path of the image via tokens. you may see the site (www.posts.gr).

Thanks in advance and thanks for the great module.

@sigalasgeo re. #45

I opened a new issue #2146495: Implement Textimage tokens to retrieve images' URI/URL. Let's continue there and leave this issue rest in peace :)