smd_gallery: super-flexible gallery generator

adastra · 2009-02-21 21:20:15

Bloke —

Doesn’t look like many people have been trying out “directory=”. It’s what makes sense for my app; I have over 1,000 images in the file system, and haven’t found any way to import them into txp in bulk.

Anyway, the page includes the code:

<txp:smd_gallery form=“archive” directory=”/var/www/files-not-backed-up/2008/12” debug=3 />

and the effect is: blankness. No output from smd_gallery. The debug=3 results in the following, which you may find helpful but doesn’t convey anything to me:

++ COMBOs ++
array (
)
++ RECORD SET ++
array (
)
++ FINAL OUTPUT ++
array ( 0 => ‘’,
)

Ideas?

Bloke · 2009-02-21 23:16:04

adastra wrote:

Doesn’t look like many people have been trying out “directory=”

Yep, as far as I know you’re the first besides me.

the effect is: blankness.

Off the top of my head — aside from the obvious verification that the given path definitely exists and is readable — does the directory you specify contain any files at all? Or is it just other subdirectories that contain the images? The default for sublevel is 0, which means “don’t enter any subdirs underneath the given dir”. Try sublevel="all" and see if that helps. Aside from that, erm, ummm. Not sure.

I have it working here, though I do get an annoying warning message in site debugging mode about the lack of ‘thumbnail’. It’s harmless but I’ve just fixed that in my development version.

adastra · 2009-02-22 03:44:05

That directory contains 31 .gif files. sublevel=“all” doesn’t change anything. Hmm, “readable”… don’t know under what user context Apache runs, but every directory in the path above is world readable.

Tried it with a different directory path: that for the site /images. Twelve .gifs there, same empty result.

Beginning to think my form is the problem. What sort of contents in a form would be appropriate for directory=?

Last edited by adastra (2009-02-22 04:11:51)

Bloke · 2009-02-22 13:28:18

adastra wrote:

Hmm, “readable”… don’t know under what user context Apache runs, but every directory in the path above is world readable.

It could be that (clutching at straws), but I’m not sure how to “prove” it is the case. I don’t suppose that dir is under the doc root is it? If so you could try accessing it with directory="http://site.com/blahblah" as long as you have allow_url_fopen switched on. Same goes for the ‘images’ dir. Try specifying a URL and see if it finds those 12 gifs.

Beginning to think my form is the problem.

I wondered about this as well, but since the plugin debug shows no ‘records’ pulled from the directory I figured it was more likely to be the path. FYI, the plugin reads the dir, filters it with match and sublevel and returns a list of all matching files. At that point, the “RECORD SET” is available and debug should show which files are found. Then the plugin continues as usual to make up the replacement variables and stuff. Since your debug shows no record set, it doesn’t matter what you put in your form, you’ll see nothing.

What sort of contents in a form would be appropriate for directory=?

Any TXP/HTML tags employing any of the replacement variables that ‘make sense’ for a directory are available. e.g. {id} (the filename), {imagepath}, {author} (the ID of the user who ‘owns’ the file, if available from the operating system) and so on. Some things such as {thumburl} probably don’t make sense, since it just adds a ‘t’ to the filename.

This is a strange one. If I think of any further tests to run to work out where the problem lies I’ll shout, but I can’t think of anything right now. Hmmmmmm. Anyone?

Last edited by Bloke (2009-02-22 13:30:35)

adastra · 2009-02-22 13:40:10

Hate to say, but directory=“http://site.com/images” also results in blankness. Debug info is identical. (Version 0.5, don’t think I mentioned.)

Bloke · 2009-02-22 13:52:52

adastra wrote:

Hate to say, but directory=“http://site.com/images” also results in blankness.

Baffling. OK, desperate measures: plugin hack time. Go right to the bottom of the plugin to the smd_doDirectory function and find the two lines:

if ($handle = @opendir($dir)) {
   while (($file = @readdir($handle)) !== false) {

Remove the ‘@’ signs on both lines so we can see any PHP errors that may be given. Then, a few lines above that (line 738ish, after the matchexc = ... line) add some more debug:

dmp($lst);
dmp($dirinc);
dmp($direxc);

Make sure your sublevel attribute is not used in the tag and render your page. From the output we should be able to see if it’s smd_lib at fault (which version of smd_lib do you have installed, btw?) or whether PHP itself is choking on the directories. If you don’t want to publish the diagnostic stuff here because of directory names and things, drop me an email with it in.

Last edited by Bloke (2009-02-22 13:53:44)

adastra · 2009-02-22 14:38:54

That got results.

Couldn’t find a public email for you, so here it is sanitized:

__________________

http://thesite.com/images/
array ( 0 => ‘http://thesite.com/images/’,
)
array (
)
Tag error: <txp:smd_gallery form=“archive” directory=“http://thesite.com/images/” debug=3 /> -> Warning: opendir(http://thesite.com/images/) [function.opendir]: failed to open dir: not implemented on line 747
++ COMBOs ++
array (
)
++ RECORD SET ++
array (
)
++ FINAL OUTPUT ++
array ( 0 => ‘’,
)
__________________

And when I tried with directory=“the original directory”, which is not under the docroot, here’s the result:

__________________

Tag error: <txp:smd_gallery form=“archive” directory=”/var/www/files-not-backed-up/2008/12” debug=3 /> -> Warning: opendir() [function.opendir]: open_basedir restriction in effect. File(/var/www/files-not-backed-up/2008/12) is not within the allowed path(s): (/var/www/vhosts/thesite.com/httpdocs:/tmp) on line 747
Tag error: <txp:smd_gallery form=“archive” directory=”/var/www/files-not-backed-up/2008/12” debug=3 /> -> Warning: opendir(/var/www/files-not-backed-up/2008/12) [function.opendir]: failed to open dir: Operation not permitted on line 747
__________________

In the first case (under docroot), the problem may be the lack of allow_url_fopen as you mentioned earlier. (What / where is this switch? Apache option? PHP default setting? Is it settable via txp or only from the outside?)

In the second case (not under docroot), there is a restriction in place called open_basedir, which in fact sounds like a very sensible restriction to avoid getting pwned incessantly.

Bloke · 2009-02-22 15:00:32

adastra wrote:

Couldn’t find a public email for you:

I forgot that new forum accounts can’t see the email addresses, and Google still hates me. For future reference: my site contact form.

Warning: opendir(http://thesite.com/images/) [function.opendir]: failed to open dir: not implemented on line 747
Warning: opendir() [function.opendir]: open_basedir restriction in effect. File(/var/www/files-not-backed-up/2008/12) is not within the allowed path(s): (/var/www/vhosts/thesite.com/httpdocs:/tmp) on line 747

Aha! That explains it. I knew I should have given a plugin option to turn the PHP functions into “verbose” mode. Might add that in future so this sort of thing is more easily detectable.

Yes, I’d concur that the http:// case is due to allow_url_fopen not being set in the php.ini file of your host. Not sure it’s overridable by you, but Google — or someone with a better knowledge of Apache than me — can probably help here. Perhaps try adding:

php_value allow_url_fopen 1

in your .htaccess file?

For the 2nd case, open_basedir would certainly be a good reason for failure! Depending on how your host has set up your environment, you (or more likely they) may be able to add that directory to the list of allowable dirs that PHP can ‘see’. It’ll very much be down to how much security (or lack thereof) that your host has implemented or wishes to restrict.

If you can’t change the values yourself and your host won’t do it then I think the only option is bulk import to TXP. Never done it myself, but many people report that fpx_image_import is top banana for uploading multiple images to TXP. Alternatively there’s EBL_Upload.

adastra · 2009-02-22 22:43:27

Progress: now the plugin sees files in the file system. The magic that worked was in the Apache config for this domain:

php_admin_value open_basedir “/var/www/”

(I have root on my own VPS, so the security can be as loose as I can tolerate.)

This did not seem to change anything, when using directory=“http://thesite.com/images/”:

php_admin_value allow_url_fopen 1

but that’s OK. I only tried this route because I couldn’t (before) see files outside the docroot.

Now the plugin sees the files, but that doesn’t translate to a sensible graphical result. In the form, using src=”{imagepath}” fails because of the lack of a “file:///” prefix — and not sure that would work even if I could figure out a way to insert it. What shows up in View Source is <a href=”/var/www/files-not-backed-up/thesite.com/test/01.gif”> and so on. Clearly that’s not going to result in an image appearing in anyone’s browser.

I sent a note via your contact form linked above; let’s go off-forum for a bit while the grisly details are thrashed out.

maniqui · 2009-02-24 03:24:44

Hi Bloke,
thanks for your detailed reply and sorry for this delayed reply.

Do you know what? This was one of those “twilight zone” mysteries…
Let me explain:

Short version: while gathering all the information you asked, and while doing some testing, I just re-saved the category (under Content -> Categories -> Image categories) and then it everything started to work as expected. The only thing I changed before re-saving the category, that was the category titles (because I’ve made a mistake) but the category *name* (“comodidades”) remained the same.
That simple change magically fixed the issue.

Long version: as said, I was doing the tests you suggested and also gathering the information you asked. I was copy-pasting the SQL queries on a notepad, both for smd_gallery 0.46 and 0.5, and in both languages.
Although I’m not a SQL expert, I compared the 0.5 working query (english) with the 0.5 not-working query (spanish), and there were no differences at all (just en_gb and es_es suffix changed).
So, I started to think there should be something else failing somewhere.
Then I went to rss_db_admin_manager and ran the “offending” query, and it returned duplicated images for the category “comodidades”.
That’s when I noticed I made a mistake on the category titles (I wrote both of them in english), so I went to the Category tab and re-saved and ran the query again, and voilà!! It worked…

Probably, that category table/column was on some kind of MySQL limbo.

Thanks and sorry for the faux bug report.

koobs · 2009-02-24 09:14:57

Hi,

I set up smd_gallery at the weekend for a site and added lam_image_uploader to streamline the uploading of images for a very “unsavvy” client.

I’ve been really impressed with it so far but one thing is bugging me and wondering if anyone can help out?

I can’t seem to use a combination of integers and ranges in the article image field. eg: inputting “1-4, 5” will output only 1 & 5. Reading through the documentation it seems it should display 1,2,3,4,5.

Have I missed something

Thanks

Bloke · 2009-02-24 10:11:59

koobs wrote:

inputting “1-4, 5” will output only 1 & 5

Yowzers! Confirmed bug in smd_lib. Thanks for finding that.

Here is some hold music…

Textpattern CMS

Textpattern CMS support forum

#361 2009-02-21 21:20:15

Re: smd_gallery: super-flexible gallery generator

#362 2009-02-21 23:16:04

Re: smd_gallery: super-flexible gallery generator

#363 2009-02-22 03:44:05

Re: smd_gallery: super-flexible gallery generator

#364 2009-02-22 13:28:18

Re: smd_gallery: super-flexible gallery generator

#365 2009-02-22 13:40:10

Re: smd_gallery: super-flexible gallery generator

#366 2009-02-22 13:52:52

Re: smd_gallery: super-flexible gallery generator

#367 2009-02-22 14:38:54

Re: smd_gallery: super-flexible gallery generator

#368 2009-02-22 15:00:32

Re: smd_gallery: super-flexible gallery generator

#369 2009-02-22 22:43:27

Re: smd_gallery: super-flexible gallery generator

#370 2009-02-24 03:24:44

Re: smd_gallery: super-flexible gallery generator

#371 2009-02-24 09:14:57

Re: smd_gallery: super-flexible gallery generator

#372 2009-02-24 10:11:59

Re: smd_gallery: super-flexible gallery generator

Board footer