Support/Comments for Easy 2 Gallery 1.4.0-RC1

Evo 1.0.4 / PHP Version 5.2.12

I’ve just test clear module install...
1) installation without errors, if directories assets/modules/easy2/includes/configs
and assets/gallery (or your custom one) has full permissions (777) - maybe better to mention these stuff in module installation manual
2) First look in module panel, I’ve got this error:



Thx.

Over write with the attached files. edit: use package.
This is included the update on random galleries.
This is supposed to be r204, but google is temporary unavailable.

Now it’s clear, continue testing...

Thx

Getting a parse error from my e2g implementation, as well as some bug messages. I just installed it, want to run a simple test, and here are my exact steps:

1) After install, I made basic configuration changes, including turning debug on, set image height and width to 400, changed Thumbnail resize to ’resize’, turned watermark to ’off’, and turned comments ’off’.

2) I uploaded 3 images, created a folder, and moved the images into the folder (ID is ’3’).

3) I pasted the following snippet: [!easy2? &slideshow=`simple` &gid=`3` &ss_w=`600` &ss_h=`400`!] into a template and assigned the template to a resource

A couple of things are now happening:

1) I now see an index file within the image folder I created. Is this normal?

2) When I synchronize e2g, I get the following message, repeated for each file within the new folder, as well as for the generated index file:

message: 243 : ../assets/images/gallery/ColumbiaR/Cliff_Swallow_Tending_Her_Young_flat.jpg is NOT a valid folder, probably a file.

3) When I try to view the resource, I get the following parse error:

« MODx Parse Error »
MODx encountered the following error while attempting to parse the requested resource:
« PHP Parse Error »

PHP error debug
Error: getimagesize(assets/images/gallery/Columbia/index.html) [function.getimagesize]: failed to open stream: No such file or directory
Error type/ Nr.: Warning - 2
File: /Applications/MAMP/htdocs/assets/modules/easy2/slideshows/simple/simple.php
Line: 42
Line 42 source: $dim = getimagesize($_ssfile[’src’][$i]);

Parser timing
MySQL: 0.0006 s (0 Requests)
PHP: 0.0114 s
Total: 0.0120 s

I am running MODx v1.0.4 internally with MAMP, MySQL 5.1.44, PHP 5.2.13, and e2g 1.4.0-RC1

What am I doing incorrectly?

Oh my... new features, new options... new encoding function. And I was nearly ready with my UTF-8 version.

Goldsky is there any chance you could grant me access to SVN? We could code it together. In this case you could undo all my changes, but at least my work will not be lost. It’s my proposition. Think about it. We can do more together - for sure. And I speak Russian, so I could help you with older comments too

EDIT:
I’m thinking about the UTF-8. You wrote:
Quote from: goldsky at Jun 16, 2010, 12:00 AM

The ’e2g_decode’ and ’e2g_encode’ were supposed to bridging the different encoding of each of machines.
Like I usually said, since I don’t use irregular character (of Latin-1) in my country, I only test this against Iñtërnâtiônàlizætiøn text.
Go ahead, post your fixes on this. I’ll include that into the package.

Anyway,
I believe, this encoding should also applies the set_locale variable.
I’ve dug the MODx’s charset (in manager/includes/charsets.php), it realizes me that I should include the set_locale option in the language files.

So you’re worried about systems compatibility. OK. I already make an assumption that if somebody wants to use unicode charters then they’ll have an unicode encoding used for database and filesystem. But if we’re so worried about that users who wants to use unicode but they using Latin in Database... so we could make that unicode (url) encoding trick which I already mention some time ago.

Here are two interesting articles about handling UTF-8 in web apps:
http://www.dangrossman.info/2007/05/25/handling-utf-8-in-javascript-php-and-non-utf8-databases/
http://randomchaos.com/documents/?source=php_and_unicode

And as regards to ’e2g_decode’ and ’e2g_encode’ - you absolutely abusing that functions. Why should we multiple times encode and decode some string which we perfectly know what encoding it use? It’s inefficient and redundant. And why should we decode UTF-8 to the ISO-8859-1 which is made be utf8_decode? It’s nearly always a lossy process. So if you decode UTF-8 to ISO-8859-1 and than encode it to UTF-8 you loss information about characters. Nope. It’ll not work that way

My proposition is to:
a) make sure that names of uploaded stuff are valid for filesystem and encoded in UTF-8 if not we should rename it instantly to something that is valid for filesystem (remove bad characters &%$ etc. which could generate problems) and encode it with UTF-8. There are serious problems with encoding detection with PHP. I assume that if we’re using UTF-8 encoding in the e2g header than if somebody will upload file with upload form then its name will be encoded in UTF-8 too. If not, oh well... we must have some margin for failures. If we don’t interpret filename correctly, then the user will be able to rename that file from ’edit’ form inside e2g.

b) if somebody upload file without e2g interface (e.g. through FTP) then the same process which I’ve mention above should be apply to the synchronised files.

c) same thing with ZIP

d) we can’t save and download ZIP using ZipArchive class files with utf-8 encoded filenames. And we can’t do anything with it - it just incompatible with UTF-8. The only solution for that problem is to use other packaging class or just uri encode all filenames, so we’ll using just ASCII characters for saving UTF-8 characters.

e) when we display photos with UTF-8 names we providing url to them through rawurlencode - no more e2g_decode/encode here. It’s work quite nice with UTF-8 characters. No problem with it till now.

I’m already done with that stuff. I can send you my version, but it’s built on previous version of e2g. You’ll be the judge.

Quote from: wpicotte at Jun 17, 2010, 01:38 PM

Getting a parse error from my e2g implementation, as well as some bug messages. I just installed it, want to run a simple test, and here are my exact steps:

1) After install, I made basic configuration changes, including turning debug on, set image height and width to 400, changed Thumbnail resize to ’resize’, turned watermark to ’off’, and turned comments ’off’.

2) I uploaded 3 images, created a folder, and moved the images into the folder (ID is ’3’).

3) I pasted the following snippet: [!easy2? &slideshow=`simple` &gid=`3` &ss_w=`600` &ss_h=`400`!] into a template and assigned the template to a resource

A couple of things are now happening:

1) I now see an index file within the image folder I created. Is this normal?

Yep. Absolutely normal. It’s only to protect all the folder contents.

Quote from: wpicotte at Jun 17, 2010, 01:38 PM

2) When I synchronize e2g, I get the following message, repeated for each file within the new folder, as well as for the generated index file:

message: 243 : ../assets/images/gallery/ColumbiaR/Cliff_Swallow_Tending_Her_Young_flat.jpg is NOT a valid folder, probably a file.

I use is_validfolder() and is_validfile() function, not PHP’s default is_file() function.
The notice comes from is_validfolder’s checking notice after you’ve set the debug=on.
It check against the file extension & folder with dot within its name.

Quote from: wpicotte at Jun 17, 2010, 01:38 PM

3) When I try to view the resource, I get the following parse error:
« MODx Parse Error »
MODx encountered the following error while attempting to parse the requested resource:
« PHP Parse Error »

PHP error debug
Error: getimagesize(assets/images/gallery/Columbia/index.html) [function.getimagesize]: failed to open stream: No such file or directory
Error type/ Nr.: Warning - 2
File: /Applications/MAMP/htdocs/assets/modules/easy2/slideshows/simple/simple.php
Line: 42
Line 42 source: $dim = getimagesize($_ssfile[’src’][$i]);

This is odd. This is particularly comes from the simple slideshow file.
This is why I use my custom is_validfile() file, because originally it will only allow file with extension: jpg, jpeg, gif, and png. It will skip html.
Do you get the same error with other slideshow?

Quote from: fixedmachine at Jun 17, 2010, 04:05 PM

Oh my... new features, new options... new encoding function. And I was nearly ready with my UTF-8 version.

Goldsky is there any chance you could grant me access to SVN? We could code it together. In this case you could undo all my changes, but at least my work will not be lost. It’s my proposition. Think about it. We can do more together - for sure. And I speak Russian, so I could help you with older comments too

AWESOME!
It is true that I should handover this specific development part to people who understand this, like you.
I’ve PM-ed Temus, who gave me the access, about your proposal.
I believe he doesn’t mind, but just wait for his respond.
So perhaps, should we should split the i18n development to different class file?
so we don’t have to overwriting to each other’s development?
Just a consideration, this is what Temus said: http://code.google.com/p/easy2modx/issues/detail?id=20#c8

To get you in path, the RC2’s primary goals are:

• Integrating YAMS with Easy 2 Gallery
• Easy 2 Gallery’s plugin, said in english: make the E2G file explorer available in the MODx’s resource editing page.

bugfix:
RC1-r204: easy2/tpl/pane.comments.in.php, line 89:

Quote from: goldsky at Jun 17, 2010, 07:06 PM

AWESOME!
It is true that I should handover this specific development part to people who understand this, like you.
I’ve PM-ed Temus, who gave me the access, about your proposal.
I believe he doesn’t mind, but just wait for his respond.

Just great. So I’m waiting for his answer And let’s code!

Quote from: goldsky at Jun 17, 2010, 07:06 PM

So perhaps, should we should split the i18n development to different class file?
so we don’t have to overwriting to each other’s development?

Hmm. We can’t totally separate i18n from other code. It’s too much involved into other functions. Of course we could make the class structure more hmm... objective It would be even desirable.

I don’t know if moving whole project to GIT Hub wouldn’t be appropriate. I know... developing history in SVN, but in GIT creating Trunks and merging it down without conflicts is much more convenient. It’s only my proposition. Maybe it’s not worth it - we’ll see in practice, when we’ll be working together with SVN.

Quote from: goldsky at Jun 17, 2010, 07:06 PM

To get you in path, the RC2’s primary goals are:

• Integrating YAMS with Easy 2 Gallery
• Easy 2 Gallery’s plugin, said in english: make the E2G file explorer available in the MODx’s resource editing page.

I didn’t work with YAMS yet, so for now I can’t help with that problem. But its not a problem for me to learn it

Second: hmm, I see that it was just a concept that piloter thrown and then he disappeared. They didn’t even discuss that idea. You see, I’ve created that simple TV snippet for choosing gallery displayed for selected document. Do we really need to display whole E2G inside another tab?

I thought that our goal is to create centralized photos library independent from resources tree. There are other galleries that are dependent from MODx doc tree e.g. EvoGallery, MaxiGallery.

The ManagerManager plugin for E2G will be quite simple to provide - just something like MaxiGallery backend. But it’ll be just the E2G module interface inside an iframe. How should we connect it with resource? Because just providing interface of E2G inside another tab is redundant.

It’ll be fantastic feature to create Custom TV for E2G. You know what I’m talking about?
http://modxcms.com/forums/index.php/topic,49153.0.html
I can imagine Custom TV with just a gallery list and uploading feature, and possibility to select gallery/galleries to display inside currently edited resource. This would be great

But...as you know, Custom TVs are not integrated with original MODx distribution, and need patching of MODx core. We need to wait until MODx 1.1 I’m afraid for that feature.

EDIT:
IMHO we could totally resign from encoding option. UTF-8 is perfectly compatible with ASCII, so if one don’t use any ’fancy’ characters then it’s not a problem for him. If we’ll use that unicode-uri encoding then we’ll use only ASCII characters for UTF-8 and in theory... everything should be fine for everyone... without worrying about the locale and all that stuff.

I use is_validfolder() and is_validfile() function, not PHP’s default is_file() function.
The notice comes from is_validfolder’s checking notice after you’ve set the debug=on.
It check against the file extension & folder with dot within its name.

I turned the Debug option on from within the e2g module. Is that accessing the is_file function? If so, why have that option at all? Where do messages generated by is_validfolder()/is_validfile() appear? Regardless, as long as those messages are not symptoms of a real issue, all good. I can switch it off.

This is odd.

Good. Glad I’m not actually going crazy.

This is particularly comes from the simple slideshow file.
This is why I use my custom is_validfile() file, because originally it will only allow file with extension: jpg, jpeg, gif, and png. It will skip html.
Do you get the same error with other slideshow?

I do not get the same error from each, but I get strange behavior, and none have functioned as intended. One gave me an divide by zero error, another returned a blank document (nothing was passed to the browser). I can document the behavior each generates, if that’s helpful in ascertaining the cause of all this.

function is_validfile() & is_validfolder() are in the e2g.public.class.php

do you have any error in your apache’s log?