I created this patch after I fixed some problems I had with
textimage. First issue is related to the path that's used for
generating the image. I suppose that using 'textimage/' as
path is sufficient as it is just a callback path and has nothing
to do with files directory. Related to this, there is no need in
extracting and exploding the path from REQUEST_URI as
Drupal does that by itself when used with '%' in path name.
The second issue is related to image format. I suppose that
the format handling can be improved by extracting it from the
path and moving it in preset. There the user can choose only
from available formats and thus avoid typing errors. This also
removes the need to type the extension after the necessary
message is entered.
This patch enables the user to type an URL like this:
http://www.example.com/textimage/mypreset/mytext
Thanks for Textimage!
PS: Still, I have an issue with redirecting the user with drupal_goto()
when used in conjunction with i18n module. So, if the generated
image has the path sites/default/files/textimage/1/1227654379.png
then the redirected URL will generate a 404:
http://www.example.com/en/sites/default/files/textimage/1/1227654379.png
| Comment | File | Size | Author |
|---|---|---|---|
| textimage_path_format.patch | 6.77 KB | igor.stirbu |
Comments
Comment #1
decipheredHi Igor,
Haven't had a look at the patch yet, but just a small bit of feedback in the meantime;
The reason I use REQUEST_URI is to catch as many extra characters as possible. While this may not be necessary in the D6 version, it certainly is with the D5 version. The previous method, func_get_args(), missed a few non-alphanumeric symbols like '&'.
Ultimately I would suggest not even using the URL based generation of textimages, instead using theme_textimage() as it provides better support for characters, and large quantities of text.
As for the removal of the file type from the URL, I like to offer choice. Removing it from the URL would lock users to the profiles default type, which may be ok for some people, but may be a hinderance for others. I will however look into this further.
As for the i18n issue, I will have a look into it and see what I can figure out.
Cheers,
Deciphered.
Comment #2
decipheredi18n issue moved into it's on issue: #371753: i18n support.
Issue closed as nothing to do.