14 replies to this topic

[sandra-ch]

hi there
i have a problem with one site with many galleries (each on its own site).
the pictures are not shown but the login (authenticate_visitor) works and in the administrationarea of EtoGal i'm able to upload pictures, change descriptions and so on.

Linux
Etomite Content Management System 0.6.1 Final (PL:3) (Prelude)
PHP Version 4.3.9
Apache/2.0.46 (Red Hat)

the galleries has chmod 777
The images and thumbs has 666 / 644

anybody has an idea whats wrong or what i can try to solve the problem?
thanks in advance
sandra-ch

[mikef]

What do you mean by

one site with many galleries (each on its own site)

could you give me a url to look at please, and the page contents (to show what snippets you are using and the parameters they are called with).

[sandra-ch]

hi mikef
i send you the logins as a pm.
thanks for looking into.
sandra-ch

[mikef]

hi mikef
i send you the logins as a pm.
thanks for looking into.
sandra-ch

Thanks Sandra
I've had a quick look, and the etogal configuration looks OK. The version of MySQL is of concern though, as I've only had it working with versions of MySQL 4 and 5, and we have had issues with version 3 in the past.
I'll try to find time to look at it in more depth tomorrow (well ... later today now!)

[mikef]

I've looked further into this, and as far as I can see the Etomite API is not behaving quite as expected.

The getinttablerows function should just require the table name to be passed to it (in your case eto_etogal), however in order to get it to return any data I need to edit the code to pass eto_eto_etogal (ie adding in the table_prefix manually before calling the function).

I'm not able to debug the etomite API and etomite installation, so suggest you contact Ralph and ask him if he'd be able to assist.

I've put page 77 back to how it was, but left my patched version of the etogal snippet (etogalmf) and simplified template (test) in case they are needed again.

(The admin part of etogal works because it wasn't written to use the etomite API, but accesses the database directly.)

[Cris D.]

The database prefix call was added to the API fairly recently, I had similar problems with it as the documentation didn't mention the additional call. To pass all parameters to the API requires
function getIntTableRows($fields="*", $from="", $where="", $sort="", $dir="ASC", $limit="", $push=true, $addPrefix=true). Ralph suggests calling all API parameters

just to be safe

http://www.etomite.c...=...ost&p=42003

There seems to be another issue here because if memory serves me I added the "etomite_" prefix manually when I installed etogal a year ago because I was having connectivity issues as well. This could be due to the mixed use of dbQuery() which adds the prefix in the index.php file and the old getIntTableRows() API which doesn't have all parameters passed to it, leaving the prefix off.

Time to update etogal to include all parameters and a table prefix for the new API's to chew on?

[mikef]

Time to update etogal to include all parameters and a table prefix for the new API's to chew on?

Time for updates to the Etomite API to be properly documented in the Etomite releases and highlighted in announcements if they may break existing code.

I think Ralph's message meant that you need to add all parameters, up until the last one you want to change, not that you need to add every single one every time, as that would mean that PHP language features didn't work. It may be 'safer' to add them all, but if what you want is the default behaviour then it shouldn't be (and isn't, as long as the PHP interpreter follows the language specification) necessary. Its this that allows the addition of new parameters (that may be used to modify the action of a function) without breaking existing code.

if getinttablerows does not add the prefix automtically, unless you specifically tell it not to, its broken.


PS
and in any case adding all the trailing parameters makes no difference. It still needs the table prefix to be added in order to get the table data returned.

Edited by mikef, 05 June 2007 - 11:14 AM.

[mikef]

I've done one more test just to make sure that it isn't that the snippet has become corrupted.

I taken the snippet back from sandra's site, and copied it to another of my sites that also runs etomite 0.6.1.3 changing just the location of the galleries and the name of the table (both different in this case) leaving everything else the same, even choice of langauge!

it works correctly when transferred to my site.

[Ralph]

The default setting for getIntTableRows() in the 0.6.1.3 release was set incorrectly by accident... This has been corrected in the 0.6.1.4 release... Several other changes were also left out of the public release of 0.6.1.3 which is why everyone is urged to upgrade... Existing snippets will not break if using the 0.6.1.4 code base whereas they might if using 0.6.1.3... Mike's comment regarding you need to add all parameters, up until the last one you want to change is correct... I do, however, make a habit of always passing all of the parameters by personal choice...

[mikef]

The default setting for getIntTableRows() in the 0.6.1.3 release was set incorrectly by accident...

?
not in the copies I have. both 0.6.1.3 and 0.6.1.4 have the same defaults. They also have almost identical code, except that 0.6.1.4 also checks to be sure that the prefix isn't empty.

They also both appear to have an undocumented feature, whose presence is probably the cause of sandra's problem, if I'm reading the code right, and would also explain why the snippet works on my 0.6.1.3 and not on hers. ... if the beginning of the table name is the same as the table prefix, the prefix is NOT added to the table name even if the call says it should be.
Personally I view this as a bug in the etomite code. I don't expect an API function to not do what I ask it to because it thinks I got the API call wrong.

[mikef]

sandra_ch,
the problem in the etomite API mentioned above is the cause of your problems.

Possible solutions:
1) wait for the API to be fixed

or
2) backup the database and site files and then edit your EtoGal snippet to use 'etogal' and not 'eto_etogal' for the database table name and then delete all the files in the galleries and upload them again.

there is now an extra page on your site I used for testing (page 91, in the repository) that I used to check that changing the table name would work (this uses a copy of your snippet that I've eddited as above and called etogalmf) that has one image in it so you can see that it works. you might want to delete it!

[Ralph]

Setting $addPrefix=false in either the API function call or in the index.php file will resolve the issue... That setting must have slipped by me yet again... And considering how I always add it into my calls I can see how it slipped by and would result in potential errors... I could have sworn that I had changed the setting and tested it prior to release, as is evident by my previous post... Our bugfix list is rather short at the moment so it'll be at least days if not weeks before we put out new packages... I will look into modifying the documentation, however, as there are other changes and new functions that need to go in there...

[mikef]

Setting $addPrefix=false in either the API function call

?
the problem isn't that a prefix is being added, and shouldn't be, but that the prefix has been asked for, should be added, and hasn't been.

the table prefix is eto_
the table name is eto_etogal
the full table name including the prefix should be eto_eto_etogal, but the API fails to add the eto_ prefix

(I've no idea why its been set up this way, but it has)

I'm loathe to change the index.php file, as an upgrade to 0.6.1.4 (at present) would just break the site again.

[mikef]

PS
Its questionable whether the defaults are wrong in 0.6.1.2, 0.6.1.3, and 0.6.1.4 (I don't have a copy of .1 to check).

What I do believe is wrong is the additional test to see if the prefix is already part of the table name ... it might, as here, legitimately be so.

The defaults have been this way round from the option appeared, I think, since etogal works except for this special case, and wouldn't if the defaults were switched so that the table prefix wasn't added. Switching them now will break recent etogal installations and possibly other recent snippets taht have been tested with the current API.

It looks like you need to decide what you're going to break ...

Edited by mikef, 05 June 2007 - 04:35 PM.

[mikef]

least worst is probably leave it as it is, except extend the comments in index.php to explicitly state that the prefix will not be applied if it matches the start of the table name. If that had been there it would have saved me a lot of time trying to sort out why it didn't work.

though that does mean more work for sandra