[plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

nighthawk · 2006-12-28 10:52:55

@rbl

My 2 cents? Storing images in the db just to circumvent any safe mode issues, is like printing and filing your emails just to avoid loosing them on a server crash =)

I think that’s a little far-fetched. :) After all, it’s the purpose of a db to store stuff, especially if it’s connected with metadata (captions, etc.).

Any good and regular web host will turn safe mode off on request in a heartbeat without any complain. All it takes is one email to solve the problem.

I strongly disagree. On the contrary – it is policy for most webhosts to have safe-mode active if they host multiple users on the same machine. Deactivating it is extremely risky. Check various forums on the net – most problems people have a related to safe-mode issues they can’t get around. If your webhoster does it – good for you. :) I guesstimate that the majority of all users isn’t that lucky, though.

But when they put your site offline because your huge DB keeps crashing the mysql server, one email won’t do a thing. You’re probably looking at a dozen pictures gallery. Now imagine a 1200 pictures gallery or a 12000 one. Consider the size of the DB and ask yourself if it still seems acceptable to you.

Now that’s something I don’t see as a problem. What’s disk space nowadays? A large db (and a few gigs isn’t large) shouldn’t be difficult to handle for providers; especially if you don’t run massive queries hundreds of times a second. Besides, if you want to store gigabytes of image data, you’re probably not running a lightweight-CMS like Textpattern, anyway.

To make this clear: The gallery plugin is not intended to handle 12.000 imgs (and certainly not within ONE gallery! ;). In these cases, it’s probably more reasonable to program an individual solution which gets the job done. But for the average TXP users, the plugin should be just fine.

But anyway, what about that demo? =)

I’m working on that, but I’ll likely won’t get around to do it until the weekend. Stay tuned. :)

@lee, joel:
Working on the path problem.

Cheers!

Last edited by nighthawk (2006-12-28 10:56:45)

ruminator · 2006-12-28 14:14:56

LOL! Tease!

cnolle · 2006-12-28 14:33:43

This is a very impressive gallery script. Nicely done. I like the fact that the images reside outside the main TXP database, it can otherwise get somewhat frustrating to manage your images, this makes it a lot easier when you are working with a set of images.

It would be fantastic if you could add the ability to change the image order after upload.

- Christian

rbl · 2006-12-28 16:00:47

I strongly disagree. On the contrary – it is policy for most webhosts to have safe-mode active if they host multiple users on the same machine. Deactivating it is extremely risky. Check various forums on the net – most problems people have a related to safe-mode issues they can’t get around. If your webhoster does it – good for you. :) I guesstimate that the majority of all users isn’t that lucky, though.

True but not entirely true. You don’t need to turn safe mode off for the entire machine, just for your site. Any sysadmin knows how to do it, but with the explosion of budget hosting, they think it’s not worth their time. So let me rephrase that and say that “Any good web host will turn safe mode off on request”.

Now that’s something I don’t see as a problem. What’s disk space nowadays? A large db (and a few gigs isn’t large) shouldn’t be difficult to handle for providers; especially if you don’t run massive queries hundreds of times a second. Besides, if you want to store gigabytes of image data, you’re probably not running a lightweight-CMS like Textpattern, anyway.

I’m sorry, did you say that a “few gigs DB isn’t large”??? Wow! How big is your DB and who is your host? I’ll transfer my sites there now!! =)
Most hosts will impose you a size limit for your DB unless you have a very expensive plan, and where not talking about that.
Even if you do not plan to store GB of data, usage over time will get you there, specially if you upload hi-res images.

To make this clear: The gallery plugin is not intended to handle 12.000 imgs (and certainly not within ONE gallery! ;). In these cases, it’s probably more reasonable to program an individual solution which gets the job done. But for the average TXP users, the plugin should be just fine.

Again, usage over time can get you there. I think you are thinking about “you” and “now”, when you should be thinking about “everyone” and the “future”, another far-fetched image I know. If your script is good, a lot of people will use it. If nothing better comes along in the meanwhile, in two or three years (and they pass in a snap) a lot more people will be using it and the early adopters will have a 2 or 3 year photo collection to manage.
You are either looking at a very specific audience and/or you have little experience running a photo based site (no offense intended). It’s not by chance that the vast majority of photoblog/gallery scripts runs away from DB storage like the devil runs from the cross! It’s a dead end solution, with no room for improvement.

I’m not trying to make your mind into changing it but to offer a personal opinion on that. I’ve been using and running all kind of gallery scripts or weblog “converted” to photoblog scripts for 7 or 8 years at least. Any seasoned user won’t even touch a script like that.
If you have already done all the necessary coding to use the file system (like you say on your site, if I’m not mistaken), just integrate that into the script and leave to the user the option to use the DB or the file system. Then everyone will be happy =)

Looking forward to that demo! =)

jameslomax · 2006-12-29 12:47:05

I agree – large quantities of images in the db is unmanageable. Regular db backup, for example, would be a major problem. Nor would it be necessary; I have all my images on my hard drive, as everyone does, and don’t need to send them backwards and forwards on the internet. The only concern is you don’t have a back up of the ID that TXP assigns to each image, and I’d suggest if there’s some way of resolving that it would be worthwhile. Otherwise, it’s the best compromise to have images in a seperate directory, the way it currently is, which you can manage – back up, delete, modify in Photoshop etc – when you need to, which is not very often. DB back up, however, has to be done quite regularly.

What about this: building an image FTP function into TXP, that you could handle as easily as if it were an FTP client. A ‘window’ where you could see all your images, and then just drag and drop them onto your hard drive so you don’t have to fire up an ftp client. That would be useful. A ‘back up’ button would be even nicer, but drag n’ drop would be acceptable. Although maybe with a ‘back up’ button you wouldn’t even need to see the images, so that would be easier to build? You’d configure it to the directory on your hard drive, and then forget about an ftp client. What about that?

After running my photo sites for nearly 2 years I sometimes regret using txp because up to now, with the exception of a few invaluable plug ins that help redress it, txp has been very bad at image handling – you could almost say, “I wouldn’t recommend you to use it”! Fortunately my sites don’t involve a huge amount of work because they’re relatively small, but at jameslomax.com I now have over 1000 images and nearly 1000 individual photo ‘articles’ – every one of those had to go through the incredibly inefficient and laborious image handling of txp. I’m a good person to consider for this subject because I’ve stuck with it – as a user, not a professional coder – initially because I liked the efficiency of txp, and then because I found some assistance at these forums, which for me was invaluable.

It really is time to address this. I know txp has its origins in text management, hence the name, but image handling is fundamental in any CMS which is what txp is – an open source, lightweight, CMS. I wonder for example, how many people over the last year or two have looked at txp, seen its image handling, and thought “no way! – I’ll go and use something else!”.

Incidentally, for anyone who doesn’t know about it, this thread is probably the most important one to read for anyone interested in this subject

Last edited by jameslomax (2006-12-30 12:07:57)

hcgtv · 2006-12-29 16:28:08

jameslomax wrote:

The only concern is you don’t have a back up of the ID that TXP assigns to each image, and I’d suggest if there’s some way of resolving that it would be worthwhile.

This is the biggest issue I have with the image handling of Textpattern. I’ve never understood why the interface would take nikon_d40.jpg and turn it into 23.jpg. This has two side affects; looking at the site with an FTP client, you don’t know what image is what and when you get a hit from images.google.com, you don’t know what image you got the hit for.

Another problem, that will crop up over time, is keeping all images in one subdirectory. If you happen to get up over let’s say 5,000 images, be prepared to suffer the consequences, I know I have on other gallery systems. Your FTP client, unless instructed to, will only display a subset of the images directory. SSH in and try to clear out the directory with a rm * command, it will balk on an ext3 file system. I think image categories, should correlate into subdirectories, this way you have a better handle on your images as your site grows.

The way it stands now, maybe Crockery will change this, the only way to have a Gallery within Textpattern is either through a plugin that veers away from the current convention or by using a dedicated Gallery script.

nighthawk · 2006-12-29 22:40:19

You all certainly got a point regarding the db issues – but as mentioned previously, files also have their disadvantages. In the end, it’s a philosophy question, or a matter of what each individual user likes better, which is absolutely okay. I think time works in our favour – disk/db space is gonna increase whilst getting cheaper. :) In addition, I don’t like the idea of people being able to move files around or rename them when other data (stored in a db) is connected to it, but that’s just my personal opinion.

On a side note, I didn’t see a provider so far which limits the size of the databases (I certainly don’t have this problem, and I don’t pay that much, either, so it’s no fancy premium thingie).

I’m afraid I won’t be able to maintain two versions of this plugin – db and filesystem handling is fundamentally different, and I would need to re-encapsulate all the image accessing/processing routines in order to keep the code manageable, which I don’t have the time for at the moment – sorry. I appreciate the idea and the suggestion, though.

The only problem is the regular backup of a large db. One solution could be to store the image data in a separate table (which is excluded from the backup), and write a routine which reads the images back into the image table after a crash, maintaining the correct data relations. I’ll look into that.

But first things first – the path problem still needs fixing…

nighthawk · 2006-12-29 22:53:24

@lee, joel:
It seems like I made a mistake regarding the way how the path to wow_image.php is set – I’m using the globals array for this, which seems to be a problem on some servers.

Before I publish an updated version, can you please try this:

open wow_image.php in a text editor
Edit line 69: Replace fragment

<img src=\"" . $path . "/wow_image.php

with this fragment

<img src=\"wow_image.php

Basically, this means that you’re removing this part:

 " . $path . "/

Save and check if the pop-up opens correctly now.

Please let me know if this fixes the problem. I’ll then update the file in the distribution.

Thanks!

Last edited by nighthawk (2006-12-29 22:53:58)

nighthawk · 2006-12-30 00:52:42

Already implemented for 0.5:

Fix for joel/lee (path bug)
Separate table for raw image data to exclude from backups, auto-migration for users of v0.4

More features to come with 0.5:

Renaming galleries

Features for 0.6:

Sorting of images (difficult, need to see how to tackle this)

jameslomax · 2006-12-30 10:59:07

Can you turn the EXIF data ‘on’ and ‘off’? I personally don’t like seeing it.
You never see it, for example, when you see the work of famous photograhers ;-)

nighthawk · 2006-12-30 13:25:22

@jameslomax
Sorry, I don’t understand what you mean. The EXIF data is only used for guesstimating a default orientation correction when you’re rotating images. Why should you want to turn it on/off? Besides, it doesn’t “show” anywhere else except on the admin screen, and even there you can simply disregard the information.

jameslomax · 2006-12-31 13:13:40

I was referring to the EXIF information for photographs – the exposure and focal length of the picture, encoded in the file.

Textpattern CMS

Textpattern CMS support forum

#25 2006-12-28 10:52:55

Re: [plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

#26 2006-12-28 14:14:56

Re: [plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

#27 2006-12-28 14:33:43

Re: [plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

#28 2006-12-28 16:00:47

Re: [plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

#29 2006-12-29 12:47:05

Re: [plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

#30 2006-12-29 16:28:08

Re: [plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

#31 2006-12-29 22:40:19

Re: [plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

#32 2006-12-29 22:53:24

Re: [plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

#33 2006-12-30 00:52:42

Re: [plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

#34 2006-12-30 10:59:07

Re: [plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

#35 2006-12-30 13:25:22

Re: [plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

#36 2006-12-31 13:13:40

Re: [plugin] [ORPHAN] wow_gallery - A complete gallery manager for Textpattern

Board footer