Marc,

I've git bisected as far as 2010, and I can't seem to find a good commit. My pma_column_info table has: mimetype: image_jpeg transformation: image_jpeg__inline.inc.php and my local image is /home/alex/Pictures/x.jpeg, which has a good format.

Could you possibly confirm that this was working before merging my branch? Or could anyone provide a good image and commit where this transformation worked? Maybe my local configuration is faulty, I'll try an older version on some other computer.

-- Alex

Le 2012-06-29 11:42, Marc Delisle a écrit :

Le 2012-06-29 10:29, Alex Marin a écrit :

...

Marc,

I've git bisected as far as 2010, and I can't seem to find a good commit. My pma_column_info table has: mimetype: image_jpeg transformation: image_jpeg__inline.inc.php and my local image is /home/alex/Pictures/x.jpeg, which has a good format.

Could you possibly confirm that this was working before merging my branch? Or could anyone provide a good image and commit where this transformation worked? Maybe my local configuration is faulty, I'll try an older version on some other computer.

Alex,

with current upstream master, the transformation works, provided you have these values: mimetype = Image_JPEG transformation = Image_JPEG_Inline.class.php

These values are set if you change the structure of a LONGBLOB column, choosing appropriate values in the drop-down.

My previous table, which does not work since your commit, is using these values from pma_column_info:

mimetype = image_jpeg transformation = image_jpeg__inline.inc.php

I am testing with PHP 5.3.13.

For a reason I have yet to find, the inline JPEG transformation does not work when testing with PHP 5.4.4, and I see [BLOB - 25.9 KiB] instead of the inline image. Clicking on the link displays the full-size image, however.

On Sat, Jun 30, 2012 at 9:50 AM, Chanaka Dharmarathna < pe.chanaka.ck@gmail.com> wrote:

Hi Alex,

...

mimetype = Image_JPEG

...

transformation = Image_JPEG_Inline.class.php

I have set the mime type and browser transformation in above format in order to display images. Images are shown without an issue.

That's good, because it's not working for me with PHP 5.4.4.

But I'm getting following warning with the mime types Image_JPEG and

Image_PNG.

Warning in ./libraries/DisplayResults.class.php#4582 strpos() expects parameter 1 to be string, object given

I don't get that warning, but it is indeed a problem. I fixed it here [1]. Please tell me if you get some other warning, because I don't know why I can't see it. And also, when do you get this (f.e. when browsing a table with the Image_JPEG transformation)?

Instead, I get some other warning: in ./libraries/common.inc.php#275 date_default_timezone_get(): It is not safe to rely on the system's timezone settings. [..]

Should I do any other configuration in addition to reset the mime types and

browser transformations as Marc mentioned ?

The thing is that the old transformations (image_jpeg__inline.inc.php) are not compatible yet with the new transformations plugins. So no configuration is needed, I will first have to make this backwards compatible.

[1] https://github.com/phpmyadmin/phpmyadmin/pull/76/files

-- Alex

Le 2012-06-30 09:34, Chanaka Dharmarathna a écrit :

On Sat, Jun 30, 2012 at 4:08 PM, Alex Marin alex.ukf@gmail.com wrote:

...

On Sat, Jun 30, 2012 at 9:50 AM, Chanaka Dharmarathna < pe.chanaka.ck@gmail.com> wrote:

...

Hi Alex,

...

mimetype = Image_JPEG

...

transformation = Image_JPEG_Inline.class.php

I have set the mime type and browser transformation in above format in order to display images. Images are shown without an issue.

That's good, because it's not working for me with PHP 5.4.4.

But I'm getting following warning with the mime types Image_JPEG and

...

Image_PNG.

Warning in ./libraries/DisplayResults.class.php#4582 strpos() expects parameter 1 to be string, object given

I don't get that warning, but it is indeed a problem. I fixed it here [1]. Please tell me if you get some other warning, because I don't know why I can't see it. And also, when do you get this (f.e. when browsing a table with the Image_JPEG transformation)?

Instead, I get some other warning: in ./libraries/common.inc.php#275 date_default_timezone_get(): It is not safe to rely on the system's timezone settings. [..]

Should I do any other configuration in addition to reset the mime types

...

and browser transformations as Marc mentioned ?

The thing is that the old transformations (image_jpeg__inline.inc.php) are not compatible yet with the new transformations plugins. So no configuration is needed, I will first have to make this backwards compatible.

[1] https://github.com/phpmyadmin/phpmyadmin/pull/76/files

Hi Alex,

Now that problem is okay. The fix has merged recently.

Regards !

Chanaka, which PHP version are you using?

Le 2012-06-30 06:38, Alex Marin a écrit :

On Sat, Jun 30, 2012 at 9:50 AM, Chanaka Dharmarathna < pe.chanaka.ck@gmail.com> wrote:

...

Hi Alex,

...

mimetype = Image_JPEG

...

transformation = Image_JPEG_Inline.class.php

I have set the mime type and browser transformation in above format in order to display images. Images are shown without an issue.

That's good, because it's not working for me with PHP 5.4.4.

But I'm getting following warning with the mime types Image_JPEG and

...

Image_PNG.

Warning in ./libraries/DisplayResults.class.php#4582 strpos() expects parameter 1 to be string, object given

I don't get that warning, but it is indeed a problem. I fixed it here [1]. Please tell me if you get some other warning, because I don't know why I can't see it. And also, when do you get this (f.e. when browsing a table with the Image_JPEG transformation)?

Instead, I get some other warning: in ./libraries/common.inc.php#275 date_default_timezone_get(): It is not safe to rely on the system's timezone settings. [..]

Should I do any other configuration in addition to reset the mime types and

...

browser transformations as Marc mentioned ?

The thing is that the old transformations (image_jpeg__inline.inc.php) are not compatible yet with the new transformations plugins. So no configuration is needed, I will first have to make this backwards compatible.

[1] https://github.com/phpmyadmin/phpmyadmin/pull/76/files

Alex, about backward compatibility (BC), it's now apparent that choosing to put a script name inside pma_column_info.transformation was a decision that has shortcomings.

Maybe there should be some kind of neutral string there, that is not a script name nor a class name, but just indicates the kind of transformation. Then, the code would map this string to the exact script to call.

Anyway, we have to decide if the BC will be done by some permanent code in the transformation logic, or via a conversion script that the user has to run.

Maybe, a version number in pma_column_info would help, to see if conversion is needed.

Le 2012-07-01 05:16, Alex Marin a écrit :

On Sat, Jun 30, 2012 at 10:38 PM, Marc Delisle marc@infomarc.info wrote:

...

Alex, about backward compatibility (BC), it's now apparent that choosing to put a script name inside pma_column_info.transformation was a decision that has shortcomings.

Maybe there should be some kind of neutral string there, that is not a script name nor a class name, but just indicates the kind of transformation. Then, the code would map this string to the exact script to call.

Ok, that sounds good.

...

Anyway, we have to decide if the BC will be done by some permanent code in the transformation logic, or via a conversion script that the user has to run.

I would say that although the conversion script is easier to implement, from the users point of view, they would have to make an additional step to maintain their old databases (at first it won't work and then they would have to read about it).

Indeed, an automatic solution is better; hopefully, the conversion would take place only the first time old values are detected.

...

Maybe, a version number in pma_column_info would help, to see if conversion is needed.

When getting a new release of PMA, users can keep their old config file. Would that mean that some users will have a version number and others won't?

Version number in pma_column_info was a suggestion to detect a needed change, but it implies adding a column to this table and this cannot be done with the limited privileges that a "normal" control user has (see examples/create_tables.sql). So, I'm no longer sure we should use a version number.

By permanent code do you mean that the old format will be kept in pma_column_info for existing transformations and then treated differently depending on a version number?

By permanent code, I meant code that runs every time, instead of asking the phpMyAdmin installer to run a conversion script.

What happens when a user modifies an existing transformation, will the same old version be used?

We are not responsible for code changes in phpMyAdmin.

Le 2012-07-01 10:05, Alex Marin a écrit :

On Sun, Jul 1, 2012 at 2:20 PM, Marc Delisle marc@infomarc.info wrote:

...

Le 2012-07-01 05:16, Alex Marin a écrit :

...

By permanent code do you mean that the old format will be kept in pma_column_info for existing transformations and then treated differently depending on a version number?

By permanent code, I meant code that runs every time, instead of asking the phpMyAdmin installer to run a conversion script.

Yes, I understood that, what I meant was whether there will be some if-else sections that treat either the old format in pma_column_info ( x_y__t.inc.php ), either the new one ( x_y_t.class.php )? And if so, this leads to the next question.

...

What happens when a

...

user modifies an existing transformation, will the same old version be used?

We are not responsible for code changes in phpMyAdmin.

(I am sorry again for the misunderstanding) I meant if the user has a table that contains old transformations on columns, and he tries to modify that, what happens? If he has transformation 1 (x_y__transf1.inc.php) and wants to switch to transformation 2, will that become x_y__transf2.inc.php or transf2-neutral-string in his pma_column_info table?

To summarize, if we choose the permanent code version, will that imply treating both cases and leaving the pma_column_info unchanged for the users that have the old format? Otherwise, they will have a mixture of old and new transformation entries.

The only way I see to change them all without a script, would be to run a full update (for all of the entries) on their column_info table every time (hopefully only the first) an old format transformation is found and replace it with the new neutral string.

Let's explore another idea for a moment; if this idea is a dead end, we'll continue the previous idea.

Couldn't we keep the pre 4.0 values in pma_column_info, treating them as some kind of neutral string? Then, you could add conditions to load the correct new transformation.

On Sun, Jul 1, 2012 at 7:31 PM, Marc Delisle marc@infomarc.info wrote:

Couldn't we keep the pre 4.0 values in pma_column_info, treating them as some kind of neutral string? Then, you could add conditions to load the correct new transformation.

I implemented this in commit 3754538 in pull request 77. The names of the old transformations files are used as neutral strings and most of them seem to work, but I still did not manage to make the image transformations actually display something in my tables, using my PHP 5.4.4.

-- Alex