Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

DataObjectManager Module /

Discuss the DataObjectManager module, and the related ImageGallery module.

Moderators: martimiz, UncleCheese, Sean, Ed, biapar, Willr, Ingo, swaiba

Image Gallery not working in 2.3.4, bug?


Go to End


31 Posts   9688 Views

Avatar
tchintchie

Community Member, 63 Posts

28 April 2011 at 10:14pm

here´s a copy of my magic_quotes line from the php.ini (located in my mamp conf folder)

; Magic quotes for incoming GET/POST/Cookie data.
magic_quotes_gpc = Off

the standard value is either "On" or "1"... after changing it to "Off" the installation went without warnings and the image gallery works just fine (except for the fact that i still can´t add pics to my albums :-D

PS: not sure if it matters but I had problems using PHP 5.3.2 because it has no magic_quotes in it´s php.ini. Had to switch back to PHP 5.2.13 (which luckily is easy on a virtual server) where I could edit the php.ini as shown above. But maybe that´s just a MAMP issue....

Avatar
GRiiDWeb

Community Member, 60 Posts

28 April 2011 at 10:41pm

I'm not in front of my development machine at the moment, but I remember a bespoke php.ini file in my previous sites that i'm guessing is missing from the new server I'm working on.
My thinking is that if these are missing, problems may occur. I'll look and see what information they contain. That might be the obvious thing that's missing.

Thanks again.

Avatar
GRiiDWeb

Community Member, 60 Posts

1 May 2011 at 3:19am

Well, it's not ideal, but I added the big php.ini file from a working site on another server to this server and reinstalled from scratch using version 2.4.0 that I know has been no issue with before.
It now all seems to be ok and image gallery works like I expect it, so I can start adding the site themes and content.
I feel better today. Must be the Royal Wedding uplift that has helped.

Thanks.

Avatar
tchintchie

Community Member, 63 Posts

1 May 2011 at 3:36am

just found out that the reason I couldn´t upload any images to my albums simply was the filesize. 6MB images apparently just won´t do. Shrinked them down to a few KB and upload them bits by bits and now it seems ok. When selecting all pics of a folder (e.g. 200) it won´t work. Any ideas on what the size/number limit is?

@GRiiDWeb: glad it´s working for you now....maybe I should downgrade to 2.4.0 too :-/

Avatar
GRiiDWeb

Community Member, 60 Posts

1 May 2011 at 5:27am

Hi,
There is a set of instructions for the php.ini file that allows uploading of big file sizes. ffMpeg on the server will resize them to suitable web size.
It's a steep learning curve with server technologies when they don't right.

The lines of code are -

register_globals = false
php_value upload_max_filesize 75M
php_value max_post_size 75M

You can alter the number values to what you need them to be. Having bigger upload values would be needed if you are uploading video files.

Avatar
ngfuture

Community Member, 3 Posts

2 May 2011 at 3:58am

Hi Unclecheese,

I think there is a bug during creation directory in assets dir.

If your default language isn't english:

- new directory is in english (eg: new-imagegallery)
- when File.php class try to rename, it use i18n name, with error "Cannot move ... to ..." at line 422.

For now I haven't found which line of code cause this bug.

Avatar
tazzydemon

Community Member, 135 Posts

1 August 2011 at 11:35am

Dear Uncle Cheese..

I too was afflicted by the duplicate folder bug and eventually traced it to this code in ImageGalleryPage.php :

	function checkFolder() {
		if( ! $this->RootFolderID ) {
			$galleries = Folder::findOrMake('image-gallery');
			$galleries->Title = 'Image Gallery';
			$galleries->write();
			$folder = Folder::findOrMake('image-gallery/' . $this->URLSegment);
			$folder->Title = $this->Title;
			$folder->setName($this->Title);
			$folder->write();
			
			$this->RootFolderID = $folder->ID;
			$this->write();
			
			$this->requireDefaultAlbum();
			FormResponse::add( "\$( 'Form_EditForm' ).getPageFromServer( $this->ID );" );
		}
		else {
			$this->RootFolder()->setName($this->Title);
			$this->RootFolder()->write();
		}
			
	}

The $this->write() seems very often to not write the actual root folder under image-gallery/ but some other spurious folder number. I have not found the cause of that yet but it does not seem to matter what the number is although if it is wrong it will create an apparent "Gallery" (or whatever your page name is) folder in the root of the assets list in the Files & Images tab. It does not create a filesystem folder. If one manually sets the entry in the ImageGalleryPage table to the correct folder ID then all becomes well.

So the first question is what is the RootFolderID for? Other than the creation of spurious virtual directories if it is wrong it appears to have no other effect. I will investigate.

The second and MUCH bigger question is that I believe the entire gallery works backwards. We spend ages building up a filesystem and database of images which is easily damaged and not rebuilt using /dev/tasks/FilesystemSyncTask, whereas actually executing that function builds the ImageGallery image database in the Files & Images Folder anyway. So we wind up during development and testing with galleries we can see in Files & Images but can't use!

So why not change the ImageGallery so that when creating a new gallery we just point it to a Files & Images folder we have already created (and perhaps enabling us to add some more). Use the captions already provided. This stops reinventing the wheel so to speak and means the whole thing is far more bulletproof and self repairing than it is now where there is a separate and fairly fragile database. Indeed you could ftp images up there do a /dev/task and whammy the gallery would have them. Even the upgrade path for existing galleries would be simple.

I shall be working on this when I have time and post it.

Go to Top