Support/Comments for EvoGallery 1.0-beta1

Hi all,

Its nice to see all of this positive feedback on the EvoGallery module. I am excited to get it installed and start using it but I am running into an issue with the zip file. Whenever I try to extract the files I get an error saying ’The system could not find the specified file’

Has anyone seen this before? BTW I am using Windows XP Pro SP3.

Thanks.

Quote from: weardark at Jun 08, 2010, 08:35 AM

Hi all,

Its nice to see all of this positive feedback on the EvoGallery module. I am excited to get it installed and start using it but I am running into an issue with the zip file. Whenever I try to extract the files I get an error saying ’The system could not find the specified file’

Has anyone seen this before? BTW I am using Windows XP Pro SP3.

Thanks.

Have you tried another zip program? For example, I use IZarc?

Hi.

The wiki & explanation of this package seemed really promising, so I’m just trying to get it running on a site.

The install went smoothly (must admit I was pleasantly surprised with the install interface!), but now there’s an issue... I’m not seeing the "EvoGallery" module in the modules tab.

In does appear in module management, but refused to show up in the menu (to start managing the galleries!).

From what I can see all files are in the right place according to the install.txt instructions. There’s also an assets/galleries folder.

Any tips on where to look?

Edited

The problem fixed itself... sort of. I tried to get "Register Globals" to turn off, however due to restrictions from the host that was not possible with .htaccess. Actually, .htaccess was not allowed due to it being a windows host... learned something new again!

I contacted the host who kindly upgraded the PHP from PHP 4 to PHP 5 (at 1am sunday morning!), which fixed that problem.

When I logged in again the module did show in the menu and so far it seems to work.

I don’t know if the logging in again did the trick, or if it was a php compatibility problem (looking at the specs required now, probably that), but it’s fixed now.

Edited (2)

Finally figured it out and it looks like it’s a bug. If the gallery TV is the only TV for that template it wont show up but as soon as i have another TV I can see the gallery link. Obviously multiple TV are normally present, but as i was testing on a new install I’d not created any additional TV’s.

Thanks! That was the same problem here.

Imo, that sounds like a managermanager bug that might need to be investigated - any volunteers?

As I’m not expecting to need another template variable for this very easy website, I’ll just use MM to hide the abundant field again. Hehe.

Edited (3)
I’d like to suggest a change to the docs (http://svn.modxcms.com/docs/display/ADDON/EvoGallery) to make it clear that if you leave out docId, that it takes all photos.

From what I’m experiencing on my site now (and what is on line 14 of the snippet config.inc.php file) I conclude it gets all photos if there is no setting given, while the docs say the default will be $modx->documentIdentifier.

Modules not showing up in the menu on creation is my fault. When I added the main Modules section to the menu I never got around to forcing the menu frame to refresh on saving or deleting a new module (something like what happens when you save the Configuration). You can either reload the Manager, or in Firefox use the right-click context menu to reload just the top frame, or as you did, log out and log back in again. Whatever it takes to reload that top menu frame.

Has anyone tried to use the jQuery Cycle scroll parameters with this snippet? I’m trying to create a horiz scroll of my gallery with it, but no luck so far. It seems as though adding it to tpl.default should work, but it’s not. I also tried creating template chunks.

This call is in my template:


Worked as a charm for me.

(MODx 1.0.4 on a Windows/IIS host running php 5)

Hi,

I gave a try to some galleries today and finally stopped on Evo.

It’s really promising, however, I’m facing some really puzzling wandering.

I see all the wanted code is generated as I wanted, using jcycle type, BUT why the folders MUSt have 777 permission ?
(gallery dir and thumbs dir too)
Can’t figure out why.
if the outpout gives this :

(I customised the tpl to display thumbs instead of full size img in this first test)
then a standard 755 permissions is enough !

I have to say I let the default permission after installation and had no trouble with the module management, setting up my new gallery)

May be I’m wrong, but ...
I’d like not to recreate some $%!Joomla component with security issue.

777 is used for the scripts to make the different gallery folders and to manage the pictures through the module.

I think (but correct me if I’m wrong) you could just set it back to 755/644 or something similar if you’re not planning on using the management module to change the photos.

What influence 777 has on the security of the module? No idea, but do remember that while installing MODx you’re also making folders such as /assets/cache, /assets/images, /assets/files, /assets/media etc to writeable too. So I doubt having an extra folder (in this case, /assets/galleries) as writeable poses a security risk.

markieham,

Do you have a live URl to let us see this in action?

Thanks...

I’d rather not link to a live clients’ site as a demo, sorry

I’ll set it up on a personal site just to show it.

Edit: <link-was-here>
It uses the same call as I mentioned in my previous post, and features four pictures of our Alpaca’s. :d
This time, it’s on PHP Version 5.2.13, Linux.

I didn’t change any of the default snippet settings (such as max size).


Edit2: The above link has long been dead. As it was still getting hits though, I’ve removed the link.