Gallery 2.0 Released

uss_valiant writes "From the Gallery website: "We are incredibly pleased to announce the release of Gallery 2.0! Over three years of design and development have gone into creating the best online photo management product possible. Gallery 2.0 is the natural successor to Gallery 1, and we hope that you like what you see. Don't wait, download Gallery 2 now!" From a developers point of view, the Gallery 2 framework is particularly interesting because it's written with modern programming patterns (OOP, extreme programming, test driven development, MVC, factories, modularity, ...) in mind which is rather unusual for PHP based projects. Over 1500 unit tests ensure correct functionality and its architecture is really impressive."

Comments

Uhm, been running on my server for months....

[dfn_deux]

The article is a bit misleading, since Gallery2 has been available for sometime and has been stable enough for all but the most critical applications...

Re:Uhm, been running on my server for months....

[Anonymous Coward]

No, it's not a single bit misleading. "Gallery 2.0 Released" it was released last night right before mid night PST.

You've been running betas or RCs

Re:Uhm, been running on my server for months....

[yelvington]

Gallery2 is free software developed with the "release early, release often" philosophy, so of course it's been available for some time. But it's also been a moving target in terms of filesystem layout and API. Emerging from beta is NOT a small deal. It means that developers of add-ons can proceed with some confidence that the entire system won't turn to smoke with the next dot release.

I've been using it in a high-volume production environment since April Fool's Day. We plan on dumping it next week and moving to our own code. It's a very nice system (and a tremendous leap forward from Gallery 1), but it's wedded to a folder organizational metaphor, and we need a richer taxonomy to support potentially tens of thousands of users.

Re:Uhm, been running on my server for months....

[DaveOke]

It's their first stable release as advertised on their website. It's been in beta for quite some time.

Re:Uhm, been running on my server for months....

[smallguy78]

What is the PHP programmer's (read phpBB and other forums, this too) obsession with version numbering:

Gallery 1.5.1-RC3
Gallery 1.5-pl1

And I bet RC2 and RC1 had 2 a few tags changed and $global_title renamed to $title_global or something?! This is an app written in a scripting language not an operating system, get your head out of your asses jeez

FYI

[Anonymous Coward]

http://en.wikipedia.org/wiki/Gallery_Project

The Gallery Project is an open source PHP project enabling simple management and publication of photographs and other digital media through a PHP-enabled Apache or IIS web server. Photo management includes automatic thumbnails, resizing, rotation, and flipping, among other things. Albums can be organized hierarchically and individually controlled by administrators or privileged users.

Re:FYI

[Anonymous Coward]

So it's sorta like flickr but without tagging?

*duck!* ;-)

+5 Insightful!

[h0bbel]

RC1 was codenamed +5 Insightful, how nice :)

Re:+5 Insightful!

[Q2Serpent]

Haha, have "+5 insightful" twice in a post and get modded insightful!

Mods: The parent post was *informative*. See how it works? Not insightful, but informative.

Re:+5 Insightful!

[Anonymous Coward]

Yeah except that the fact to mod it "+5 Insightful" was "+5 Funny"... Not as easy as it sounds.

Re:+5 Insightful!

[hobbesx]

It's all in the .sig...

Re:+5 Insightful!

[sukotto]

Thank you. I needed cheering up.
I'd mod you +1 funny, but you're both already maxed out.

Extreme programming?

[Morinaka]

If they had used extreme programming wouldn't it have been done alot quicker than 3 years? Or are they saying they just had some all-nighters.

Re:Extreme programming?

[ribo-bailey]

Is that with, or without, the 'E' ?

Re:Extreme programming?

[manual_overide]

Extreme programming is iterative and agile. There is nothing about speed. In fact, many of the XP and UP texts i've read advocate DAYS spent in design meetings. Unless every software project is released by large mega-corps, developers just don't have that kind of time.

It's quite likely that following the UP exactly may slow down development significantly.

Re:paid press release on /.?

[Anonymous Coward]

For some of us, this is like the release of phpBB 3. We've been needing the features this release has for months and even years and we're excited that it is finally ready for production.

So whatever, man....

Gallery

[Saiyaman]

I have been using the Beta of 2 for Gallery for a while. I love it. It is great if you want to share photos with friends after a fun night partying. Also allows your friends to upload pictures if they are so inclined.

Re:Gallery

[Scooter]

I agree - I had used Gallery 1.3.x for years and it was "OK", but was a pain to permission up, and stored all the images below the doc-root, so it was trivial to bypass the security anyway.

All of this has now been fixed, with a robust user/group model with a permission "tree" ("view all sizes" implies "view full size" and "view thumbnail" for example), and the images stored in a dedicated data directory outside of the web server doc-root. They've also fixed that annoying "feature" of 1.x.x where it would output image URLs with the explicit host name used during the install. This meant for my old gallery, that all the image URLs were prefixed with my internal host name for the server, so you got no images when browsing it from outside (unless you had a real non-proxied connection to the Intarweb and could edit the local hosts file :P ) It no longer gets it's knickers in a twist and corrupts it's own config file either (although I suspect this only happened on certain combinations of PHP and Apache)

Gallery 2 demonstrates the ease of use of a mature project. Upgrading within 1.x.x release used to be a bit of a chore, but after unpacking Gallery 2 to a new virtual server, a couple of MySQL commands to create and permissiona new database, all I had to do was browse to the new server, and tell it where the data was for the old gallery and it just got on with it. Detected all the image tools and preserved all the comments and metadata.

The "help n fill" on the local server paths is a bit spooky, but handy. The upload options are comprehensive, even supporting Xo's "publish to Internet" function, although I can't really reccomend that - it's very slow. The best option is to use Gallery Remote - a swing app that lets you just drag images, or folders or zip files of images onto it to upload to your gallery.

It even acts as a shop, letting your customers select images to buy from smaller versions and then making them a handy zip archive for checkout time.

Now I don't have to bother emailing pictures to family and friends - I just made them a user id each, created some groups, permissioned up the albums (and it supports inheritence too for permissions) and mailed people the link :)

Fantastic job guys.

Re:Gallery

[Matt_R]

I've been using Gallery since the early v1.4's, and have found it very suitable for my needs.

G2 is a big step forward compared with G1. I've been running G2 since the beta was first released, and while I noticed a few bugs in the early betas (that's what beta versions are for after all..) the more recent versions have been really good.

Yes, you need an SQL server for this version, but for those of us running our own servers, that isnt really a huge problem. It certainly makes things much easier (I've had corrupted db files in gallery1 that were a huge pain - I couldn't delete an empty album!)

Any other ways to see it

[staticdragon]

Anyone have an alternate link or a server thats running it since the site is borked?

Re:Any other ways to see it

[trompete]

Use their SourceForge site here.

All the same files are posted there!

Does it still contain built-in spam ?

[Anonymous Coward]

I helped someone install gallery over a year ago, and to my disappointment some of the pages on it re-directed to some spamish link farm. Mostly mistyped urls going into gallery, like leaving off a slash at the end of some urls, I think.

Is that still in there ?

Gallery vs. JAlbum vs. ???

[banglogic]

I have been using JAlbum for my photo album projects for quite some time now. I like it pretty well and there are a lot of templates out there for it. I'm not crazy about it though. I checked earlier versions of Gallery a while back but I didn't care for the look of the UI and the webpages it created. Anybody try this new version of Gallery yet? Any other free web albums you guys would recommend?

Re:Gallery vs. JAlbum vs. ???

[Titanium Angel]

Since the functionality is completely separated from display, you can use its easy to customize templating system to completely adapt its look to your needs. I've been using it for a few months, and I must say I'm impressed. Seems to be the best photo gallery in town :)

Re:Gallery vs. JAlbum vs. ???

[Arathrael]

I spent a while looking at various photo galleries a while ago and couldn't find a single one I was happy with.

The main problem is that I'd like to have one photo in multiple albums. I know that was on the requested features for Gallery - anyone know if it made it into this release? (I can't check with the website not responding).

I'd also like one that doesn't arbitrarily use the terms 'album', 'collection', 'category', etc., in strange and bizarre ways. They're the same bloody thing! (in that they're all ultimately a collection of photos by some theme).

One that lets me use keywords for dynamic tagging and displaying of photos would be nice. Especially if it will let me just select keywords already used rather than typing them every time (that always goes horribly wrong since you typically end up referring to one thing in different ways, especially if there's more than one person uploading pictures).

I suspect I might end up writing my own, but if anyone can save me the trouble by pointing me in the right direction, I'd appreciate it. :-)

Re:Gallery vs. JAlbum vs. ???

[Titanium Angel]

You can definitely have a photo in multiple albums in G2. They're called linked items or something similar. There are only albums and items in Gallery. There is a root album that can contain an arbitrary number of subalbums and items. Items can be photos, movies, or anything else a plugin is available for. Some have even added support for audio items.

Regarding your complaints about keywords, they can be added to items and searched for, but there is still a lot to be done in this area. AFAIK, the next version should support functionality similar to Flickr - e.g. albums generated on the fly based on keywords.

Re:Gallery vs. JAlbum vs. ???

[Arathrael]

Thanks for the information. I'll definitely check out the linked items feature. Well, when the site starts working again I will. :-)

Re:Gallery vs. JAlbum vs. ???

[HeelToe]

Are you more interested in a dynamic website (a la Gallery FTA) or an up-front generated static html + pictures directory tree? I've written the latter for myself, and though it has not been worked on in a while, I've been looking to do a rewrite and major overhaul/enhancement this winter. If you're more interested in pre-generating html, I definitely could use some help with this project.

Re:Gallery vs. JAlbum vs. ???

[Anonymous Coward]

I have been using Quick Digital Image Gallery for a few years now. My reasons for choosing it over gallery:
1) much smaller code, much easier to understand, much easier to hack. 2) more secure than gallery. I was scared off by the large number of security problems gallery was having back then (and apparently still are, I'm told but haven't confirmed there was another one discovered recently?).

Qdig isn't for everyone though, as it is rather spartan. It does come with a web-based admin script I've never used, so some of the things I may think it lacks, might be handled by that (probably are). I generally just scp my files to the server though and manage directories (galleries) that way.

Re:Gallery vs. JAlbum vs. ???

[Enygma42]

I run a local surfing website and I've used Gallery 1.x and 2.0beta neither of which I've been very happy with.

Most of my complaints though were because it didn't really fit into my JSP framework properly. it was always just a really ugly hack. In the end I got rid of both of them and rolled my own which, while it isn't perfect, is doing the job well.

I want something more like Flickr, browse by tags, sets etc.

Re:Gallery vs. JAlbum vs. ???

[Anonymous Coward]

http://jgallery.dev.java.net/

Re:Gallery vs. JAlbum vs. ???

[Anonymous Coward]

I found JAlbum to be impractical for a large collection of pictures. Large is more than 2,000.

JAlbum kept getting out of memory when generating albums. There were three of four fixes for this but they didn't work, rather than just pushed the problem back (crash after 3,000 images, not after 2,500).

JAlbum also was regenerating ALL albums when I was only adding a new one. That was a pain. I don't know if they fixed it since.

Also I was a bit concerned with all those configuration and caption files that started to appear here and there.

I am using album now for a long time. It is a rather powerful perl script that does all that I want, except for tagging and searching.

I don't like renaming images, so I don't. Ever. I also don't like to have captions separated from the images, so I keep them in JPEG/EXIF comments (easy editing with many tools). I than generated a captions.txt file with a simple shell script and run album to generate the HTML and thumbnails.

Album is somewhat slowly developed, but the next version will hopefully have support for plugins and things will get easier from there on.

Re:Gallery vs. JAlbum vs. ???

[seriesrover]

JAlbum looks good

Re:paid press release on /.?

[pete6677]

A paid press release for free software? What the hell would they have to gain from that?

PHP != Crap Code

[ilkahn]

I have often remarked that a "Writing Maintainable Enterprise Class Systems in PHP" book would be the best thing since sliced bread for the PHP community. There is nothing so wrong with the language and the environment (although some have likened it to training wheels without the bycicle) that can't be remedied with discipline, communication, and the use of mindful quality software development discipline.

PHP has been a wonderful language in which to "put together quick solutions which grow into large projects" for me in fields from accounting to my current work in Industrial / Manufacturing! The interfaces you can write to control PLCs and generate plant floor intelligence using *good* PHP and a web server are light years beyond what is usually available on a shop floor with PanelViews and Vorne displays (Light bars...) Someone out there would be smart to write a PHP-for-software-engineering book.

Re:PHP != Crap Code

[man_of_mr_e]

The problem is, when those small projects become big projects, they usually need to be completely rewritten from scratch because the small projects were not written with maintainability in mind.

This is the primary problem with languages like PHP. There is *NO* structure to them, no type strictness, no standard practices. ASP (original) suffered from the same problems.

JSP and ASP.NET have a lot better structure to them, and standard practices, not to mention tools that follow them.

Re:PHP != Crap Code

[B3ryllium]

I've found that the lack of structure to some PHP programs can be beneficial; you can write a one-off program, then refine it piece by piece into usable code. But, that said, I have some system design experience in C++ and Java, so I tend to structure my code a lot more logically than some people.

Re:PHP != Crap Code

[ilkahn]

I guess that's sort of the point I wanted to make, is that with some foresight and proper discipline, those small projects, when they become big projects, don't need to be rewritten from scratch, if maintainability was in mind from day one. Take PEAR::DB or one of the more advanced O/R mapping PHP frameworks (such as Propel), throw a decent templating system on there (such as Smarty), keep your code highly cohesive and loosely coupled, and the benefits of the language and the libraries are *massive*.

I spent 4-5 years trying to get JSP to work as a "rapid development prototype to full scale application" environment, and I constantly ran into issues with Tomcat, Jasper, JAR file surprises, all of the warts that come with the Java language, etc... I switched to PHP for all "non-transactional" code when I did a study whereby I analyzed the amount of time it took one of my teams to react to "changing customer requirements" utilizing PHP/Apache as opposed to how much time it took another team of mine to react to similar requirement changes using JSP/Tomcat. I am not saying that JSP couldn't have worked, it's just that it seemed to not really have as many benefits as I would have liked for an environment that required as much agility as that which I found myself in.

I have to admit, my experience with ASP is nearly nill, as I have not been able to convince any clients to allow me to test out MS platforms controlling plant floor hardware.

All that being said, when my company writes something that requires "transactional integrity", we do pick Java for the backend... it's just that those situations in my field really are few and far between.

Re:PHP != Crap Code

[NickV]

You're comparing a decent templating engine (Smarty) with crap Java technology (JSPs.) Most modern Java programmers disdain JSPs and use other, better templating technologies. Try using Velocity . Requires no recompiling when you make changes and is a very very easy templating language that provides an amazing amount of power (you literally can drop items into a hashtable of VelocityContexts and then access them by using "$" notation... such as "$user.name") If you want something that will really rock your world, check out JSF or Tapestry (it turns web programming into writing an event-driven application, like desktop apps.)

The problem with most PHP applications is that they don't scale. I don't mean that in a "PHP SUXORS! YOU CAN'T WRITE S$!@ IN IT"... I mean that most PHP applications aren't built with any real caching implementations (like this gallery software, or phpbb, or nuke, etc...) and the PHP frameworks that I looked at don't really provide that functionality.

The stuff availble for Java is just so much more powerful. You have the Hibernate OR mapping package that provides an amazing amount of OR work for you, including the ability to plug in multiple transactional caches, session caches, database connection pools (including the ability to have clustered caches across multiple boxes.) You have complex messaging architectures to talk to and keep multiple machines in sync. You have great web service APIs and great search engines that can be plugged in. Stuff to that degree just doesn't exist for PHP.

It often shocks me to see so many "Enterprise Level" PHP apps released with no caching implementation... you shouldn't see ANY home page hit a database on every hit. (And yes, you can easily avoid stale content by eviction, injection routines.)

So yes, you can definitely write decent stuff in PHP. But for the highly scalable enterprise environment, the libraries and packages that exist for Java and ASP just don't exist.

The other thing I hate about PHP is that there just is no IDE that is of the caliber of Eclipse for PHP (and PHPEclipse just ain't there yet.) A professional IDE allows me to introspect objects, trace stacks, change variables on the fly per hit and control each thread individually. This kind of power makes debugging and performance testing so much easier and more powerful than a PHP app. Good luck trying to seriously profile a PHP app...

So yea, PHP has it's place. It's wonderful for quick one-offs. I just wouldn't want to code a massive user load, transactional, high availability, multiple machine cluster application on it.

Re:PHP != Crap Code

[ngunton]

FYI, You don't need caching to be a part of the application server. Just make sure you generate good expiration times for your pages, and then use a reverse proxy front-end server. The proxy will cache requests, and pass new ones to the backend. I use this with great results on mod_perl, with a lightweight apache front end on the same machine for the reverse proxy.

Re:PHP != Crap Code

[ilkahn]

I actually agree completely regarding caching... The proliferation of "databases that seem quick enough" has led to an entire generation of programmers that think that it's perfectly reasonable to do a handful of database queries per page load.

However, in my particular case, I have different needs. My company writes "shop floor intelligence" systems in which PHP is my *middleware* language. We use Smarty/PHP to generate XML/[other streams] from proprietary interfaces to PLCs or embedded shop floor systems. This XML has to have whatever the state of the machine is *at that moment.* These systems are not neccesserally "Hard real time", but they need to be very performant. We feed the PHP systems XML configurations which tell the middleware which series of registers or memory locations on the "embedded controllers" to look for state, and how to package that state as a message to the decision support systems.

The maintenance engineers / technicians on these machines may go in during a plantwide shutdown and code a series of changes to the flow control logic of a foamer (for example) in ladder logic (or even by wiring relays) and our code has to be able to take the new internal state of these machines, and turn it into a consumable format quickly. Often times, I might add, we're not notified until 4:45 on a Monday after a plant shutdown when the 1st shift build engineers realize that their decision dashboard is giving data that doesn't map the expected state of the machine. Utilizing PHP/Smarty we are able to very quickly either change the XML / whatever template, as well as the actual feed information, and in next to no time, get the line back up and running.

One of the mantras which I used to abhor was: "there can be no unplanned system downtime on a production line" because it implied to me that everyone was lazy and simply didn't want to do their job. What it turns out happens, is that when you are retooling an entire line during a 5 day plant shutdown, sometimes little pieces don't get communicated, and one of the most prized assets of a system is the ability to dynamically reconfigure it to the changes on the line, while minimizing the downtime on the line.

As silly as this sounds, even the 5 minutes neccessary in packing a WAR file, redeploying it, and having the system bootstrap itself (after having compiled it and tested it on your system) are 5 minutes that the line doesn't want to lose.

So, in closing, I 100% agree with a great deal of your sentiment. PHP is most certainly not a splendid language for a great many applications, but I think it's a narrow point of view to believe that it's useful simply for quick one-offs... all the world is not a CRUD web app :)

(I forgot to add that we use DBs simply as a place to store data until the next time that we request it from the shop floor system... so for our needs, PEAR::DB is a reasonable tool.)

Re:PHP != Crap Code

[ilkahn]

(by the way, Hibernate *is* awesome) :)

Re:PHP != Crap Code

[NickV]

That's not a bad idea, but still kind of a hack. You run the very real potentional of having stale content on your front page for as long as the page isn't expired in your proxy. Of course, you can send some information to the proxy and have it automatically expire pages that are out of date, but now you've split your application logic into a completely different location/server, making it harder to maintain.

But it isn't a bad solution if you don't have a homepage that has constantly changing critical data.

Re:PHP != Crap Code

[man_of_mr_e]

While I agree with you that you CAN create good and maintainable and scalable code in PHP (as well as just about any language), the question is, does the language, common toolsets, and best practices promote good use of the language. Also, does the language allow simple and easily caught mistakes?

The lack of any real type safety in PHP makes it difficult to track down simple typos (for example, misspelling a variable name). I don't mean syntax errors, since those are easily caught, but typo's that are not syntax errors.

The lack of any real scope in functions and the ability to RAII also make it difficult. Debugging is also pretty difficult, even if you use commercial tools (ie Zend).

Re:PHP != Crap Code

[killjoe]

"The problem with most PHP applications is that they don't scale. "

I would like to know what you mean by "scale". Even if we stipulate everything you say as being true are they really that important in order to scale your application? Is ORM mandatory for large scale application? Certainly MS does not think so because they don't reccomend ORM for .NET applications.

Let me rephrase the question. How large can a PHP application scale? Presuming savvy programmers how much load can a PHP application take before it keels over and you have to use Java.

I think that's a very important question because if you don't expect your application to scale up to the level of ebay or amazon.com it might not be worth the programmer productivity hit you are going to get from java.

Re:PHP != Crap Code

[NickV]

I would like to know what you mean by "scale". Even if we stipulate everything you say as being true are they really that important in order to scale your application? Is ORM mandatory for large scale application? Certainly MS does not think so because they don't reccomend ORM for .NET applications.

ORM doesn't really have anything to do with scalability (at least in terms of load.) I'm sorry if you feel that my reply above implied that. What I was implying is that the packages that exist for great Java ORM implementation packages already exist. And they include great caching implementations that can easily be plugged in.

In terms of how large can a PHP application scale? Is surviving a slashdotting a sufficient answer? This link today didn't die because of a lack of resources or a lack of memory/hardware, it died because of a lack of connections since it was making lots of wasted database calls that aren't necessary.

The programmer productivity hit of using Java in a real IDE for something substantial isn't as big as you might think. Sure, writing a simple web site in PHP (with bulletin board, etc) is quick and easy, but if you want to do anything that is complex I think its easier to use packages that already exist (Lucene for search, Spread and other services for messaging, Hibernate for ORM, etc, etc) then to write your own. Java just seems to have more of these that can scale well than PHP.

Plus, as I mentioned earlier, you still don't have a real IDE out there for PHP (and yes, there is something to be said about being able to trace your code line by line.)

There is no real answer to "how much load before it keels over." You have to decide if the site you're making will ever be big enough to need the withstand serious load (or its doing something really complicated.)

Of course, you should always imagine the stuff you build will become as big as ebay or amazon! :)

Re:PHP != Crap Code

[ngunton]

I agree, the issue of what to set for the expiration times is critical. I use a combination of approaches: Short expiration times (1 minute) for "what's new" type pages, which ensures that people will never see very old content (one minute is fast enough for anything but real real-time data such as stock quotes, but that's probably a case where you'd be setting 'no-cache' anyway)... this also means that the backend is being called at most once a minute for these pages, which isn't going to be a problem for any db unless the queries are just insane.

Then I also use URL arguments to make links look "new" to the front-end proxy when things change. For example, there is a 'v' field for documents that gets incremented whenever the document is modified. So then if a page is added, then all the links on subsequent generated pages have '&v=123', which looks like a new page and so the user doesn't get stale data. I also use the same technique for user options, which (as well as storing in a cookie) I compress and pass around as 'o=xxx'. This is useful for browsers, some of which do not distinguish pages which are otherwise identical but with different cookies.

Finally, user editing pages get 'no-cache', since these really are dynamic and are only being seen by one person anyway. But if I got slashdotted by someone posting a link to one of the journal pages on a popular site, the server would hardly break a sweat because it would generate that page just once and then serve it to all the other requests as static from the front-end.

I use these techniques successfully on my bike journals website: http://www.crazyguyonabike.com/

Re:PHP != Crap Code

[NickV]

Sorry, I was in a "web" frame of mind, since we were talking about a web application.

It is nice that languages like PHP are interpreted (or at least dynamically run in a way that seems interpreted) and its nice that functionality is provided out of the box. It does make it very easy to modify code on the fly in production (something that is very scary though!)

Java provides similar type of functionality too if you need it(you can do hotdeploys of .class files [sorta], and you can use other technologies such as velocity to change content rendered on the fly.) Of course, it's not standard and requires some extra work to get it to perform the same way, but its possible.

It also would not be the right tool the job you described (because PHP gives this to you for free.) Again, right tool for the right job. It sounds like you have a great implementation using PHP, just many people think PHP is the end-all-be-all and every website in the world should be LAMP. That's who I was really addressing in my post.

Re:PHP != Crap Code

[NickV]

Those are some really interesting and cool solutions to the problems high load presents on a LAMP site. I'm sure lots of those flags and parameters you added came from experimentation and testing (noticing things like IE doesn't really notice pages with different cookies but similar content are new, etc).

I did mention earlier that it is possible to code a scalable perl/php/mysql/etc application (look at /. itself.) It's just that you have to jump through lots of hoops and write alot of non-business-logic code. You had to write an implementation that added the version 'v' field to your URLs, you had to do it for your 'o' fields, you had to muck around with different content-header information for different pages.

Its great that you took the time to essentially code alot of framework or scaffold code. I hope that its extensible and can be reused on different sites (if you ever have to make a new one, hopefully you can take most of this code with you.)

The nice thing about Java (and I have no experience with .NET, but I imagine its similar) is that alot of this stuff is already done for you. You want to handle caching from your DB? Just add one line to an xml file and you're done. Caching across machines? A few more property lines. Connection pooling? Same thing. And the cache is written by the guys at Sun so you can have some confidence that its ok. If not, take one of the many others that implement the standard (or if you're really courageous, write your own.)

The nice thing about large sites (and sites that need scability) is you can focus your time on the logic of the site in Java, and not on various solutions to make sure your caching implementation works correctly.

You can definitely code a php/perl app so that it can scale well, as you did, but it requires alot of work that isn't related directly to the site.

That's all I'm saying.

Re:PHP != Crap Code

[ilkahn]

Wow... did we just have a reasonable discussion on slashdot? That's creepy. :)

But yeah, modifying production code on the fly was something that took me a while to get used to. I had come from a tradition "IT Environment" in which you had programmers coding in a dev environment, and test environments, and staging, and deployment... etc... And suddenly, I find myself in an environment where you *can't* really have a test environment. How do you test, for example, a mile long conveyor that diverts packages at 100 feet per second accross 250 diverts. Particularly when one of the primary things that goes wrong is that the electricians wire up motors backwards 1/2 the time :)

So yeah, it's been a bizarre transition, but even though I now have to routinely be *at work* by 5 a.m., I love ever second of it.

To be completely honest, I wish I could program (and have my staff program) in Common LISP or some similar language, but the fact of the matter it's that it's hard enough to find dependable programmers, much less dependable programmers willing to be at work at 5 a.m.... and even less dependable programmers willing to be up at 5 a.m. and hack functional paradigm :)

Re:PHP != Crap Code

[ngunton]

You're right, I did have to code the URL generation routine myself... but the code itself is really trivial (the hard part was thinking of the right way to do it), and yes, it is very portable to other contexts. I also think that the arguments for Java solutions can be applied equally to LAMP, particularly Perl, largely because of the existence of CPAN. I can code up some very powerful stuff very rapidly because just about anything you might need to do is probably already up on CPAN as a module. However that's another (probably endless) discussion - I think which language to use is a matter of taste and style, if you know what you're doing then you can write scalable apps in most any of them.

The stuff I did in Perl isn't really onerous at all, at least no more than any other framework out there, with the added benefit that I have full control over its behavior, and I don't inherit a lot of bloat that I don't need. Making sure to call a particular routine whenever you want to generate a link isn't hard, and as a whole it was fun to do... I keep thinking I should write this stuff up, because I don't think I've seen this approach talked about much (if at all - about all you see is the talk of using a reverse proxy, which itself is more than most people seem to be aware of)...

Ironically, I was driven to do this work with reverse proxies after my first slashdotting - the mod_perl backend was getting hit for every request, and about 40,000 people came to visit! ;-O

http://www.neilgunton.com/spambot_trap/

Subsequent slashdottings have been no problem, though they haven't actually hit crazyguyonabike itself (yet...)

Fun stuff! :)

Re:PHP != Crap Code

[Anonymous Coward]

they should have just thrown up a squid.

Re:PHP != Crap Code

[stor]

I have had years of dealing with PHP sites. PHP is a security nightmare. Just last Sunday morning I was dealing with yet-another-PHP-exploit-on-a-client-server. You might want to keep that in mind when reading the vitriol below.

Most PHP code I've looked at is vile: the people who wrote it cannot code worth a damn and seem to program completely by trial-and-error. register_globals anyone? no checking return values? Grabbing values from POST variables and using them unconditionally, without any sort of validation? Yeah, let's do that! People seem to start programming in PHP before they learn fundamental programming practices.

PHP should be more strict and not allow the strictness to be reduced. PHP should be written with security as the number 1 priority: it needs to not even _offer_ things like register_globals. You don't need a "Enterprise PHP" book, you need:

1. A hardened PHP
2. To learn how to program secure, correct code under whatever language.

Gallery 1.x is trivially exploitable (to say the least). I hope G2 is better but doubt it will go without an exploit for long. Apparently there's only been one exploit found in Gallery 2 so far and that was fixed before an official version was pushed out, so that raises my confidence level marginally.

Sorry to piss on everyone's batteries but I'm missing out on sleep because of PHP and the legions of self-styled "PHP Programmers" that can whip up $200 brochure sites that are trivially exploitable.

Cheers
Stor

Re:PHP != Crap Code

[Nurgled]

I write well-structured (in my opinion, at least) PHP code a lot at work. These things are some of my main dislikes:

• No namespaces. Once you get a few different third-party libraries loaded they start trampling over each other's class and function names. While you can name classes with a prefix (MyCrazyApp_Thing) it gets tedious to type the prefix constantly and other developers don't comply. Having standardized namespaces means that there can be the concept of a "default" namespace for the current scope and the ability to explicitly import symbols from another namespace into the current scope as appropriate.
• No higher-order functions, reflection etc. While many people would argue that these are not necessary features, it seems pointless to have a dynamic scripting language without them. Someone obviously thought higher-order functions were worth implementing (see the create_function function) but not important enough to do right.
• No variable declarations. PHP can be configured to warn if you use an undeclared variable, but I want a Perl-like strict mode which makes it into a compile-time error rather than a runtime error. This is complicated, of course, by the fact that PHP's symbol table is just one of its own associative arrays populated at runtime, and that there's no variable declaration syntax.

There are a few more, but those are the main ones that frustrate me most days. Fortunately, my job doesn't entirely revolve around PHP. That's just one project.

Re:PHP != Crap Code

[killjoe]

"In terms of how large can a PHP application scale? Is surviving a slashdotting a sufficient answer?"

No, we have seem java sites and .NET sited keel over on slashdotting too.

" it died because of a lack of connections since it was making lots of wasted database calls that aren't necessary."

I don't think that's right. In PHP you get to set an absolute limit and once that limit is reached then it stops. You can not presume the database pooling was misconfigured, it probably worked just like the author intended.

"The programmer productivity hit of using Java in a real IDE for something substantial isn't as big as you might think. "

Having done both I don't think I KNOW. I was at least two to three times more productive with PHP.

'Java just seems to have more of these that can scale well than PHP."

That's just your opinion, you have no read data to back that up. Oh also since PHP can call java classes all of those are available to PHP as well.

"Java just seems to have more of these that can scale well than PHP."

This is just misinformation. There is the zend IDE as well as few other PHP IDEs which let you debug your code line by line. Having said that I programmed for four years in PHP using Jedit and never once wished I had a better IDE. I built and maintained a very busy commerce site which made millions of dollars per month and worked like a charm on single low end dell server. I won't say it was as busy as ebay or anything but it was able to take two to 20 hits per second with only 1 or 2 percent CPU utilization and ran comfortably on 512 megs of ram (freebsd).

"Of course, you should always imagine the stuff you build will become as big as ebay or amazon! :)"

Perfect is the enemy of good. That's premature optimization.

Re:PHP != Crap Code

[stevey]

I rarely touch PHP, because I write most of my code in Perl. So feel free to hold that in mind ..

That said I've found some nice PHP code, and some bad. I think that PHP suffers a lot from people who are new to coding in general writing bad code. I don't believe this is a problem specific to PHP coders, there is a lot of generalisation which goes on "Perl is unreadable", "PHP is insecure", etc..

My biggest gripe with PHP is the inconsistent function naming. (eg. "stream_get_line" vs "readline", or "strip_tags" vs "stripslashes").

For somebody who uses PHP a lot this is probably something you just learn, but for me as an occasional PHP programmer it bites me almost every time I have to make significant changes - I find that I have to refer to the documentation far more than I'd like, and far more than I would in Perl/C/C++/Java.

Another minor gripe is the way that no two PHP installations are the same. Because functions can be disabled, or restricted, in the php.ini file you can't assume that two servers with the same version of Apache + PHP will behave in the same way. Ditto for PHP extensions.

Re:PHP != Crap Code

[Trak]

I've often remarked that "Flying to the Moon and Back on a Paper Airplane" would be the best thing since sliced bread for space exploration.

Re:PHP != Crap Code

[Anonymous Coward]

My biggest gripe with PHP is the inconsistent function naming. (eg. "stream_get_line" vs "readline", or "strip_tags" vs "stripslashes").

It is little things like that which tell you that the code was poorly designed in the first place. When trying to sniff out inferior software, I always look for little details like that.

Re:PHP != Crap Code

[NickV]

Snippy.

I've done BOTH too... I've coded my high school's 10 year reunion site in PHP and I've coded a major portal in Java.

To say that you don't "need an IDE" is great. I can use vi to code my stuff to. The point is, it is NICE to have. It is nice to be able to debug stack traces, it is nice to be able to change variables and see the effects. It's nicer to debug code this way than it is to drop variables in HTML to see what they're set to in the execution.

And, as I said before, good luck profiling a PHP app. Need to know which method is taking up most of your execution time? For all you know, one xml transformation can be accounting for 60% of your execution time... can you find that out in PHP? Sure, you can put in lots of time printouts that print to the screen or console but its certainly not as efficient as something like Eclipse Profiler.

Notice how all the stuff that I mentioned so far is free? Zend is $300 per license (and that's not the all-incompassing package)

Additionally, yes there real packages to back up my statements. Nothing out for PHP is as powerful as Hibernate, or as AspectJ, or as the profiler above or as JMS, or etc, etc...

Again, in your architecture there is no way for you to add another box, scale the application up, etc, etc... If you ever get to that point, you have to throw everything out and write it all from scratch.

You might have been more productive in PHP. How much more productive? 10%? 50%? 80%? Is it enough to compensate for the possibility that you must rewrite if your application grows dramatically?

Were you that much more productive because you are more comfortable in PHP in general? I bet someone can be just as comfortable coding in PHP as in the Struts or Tapestry frameworks for Java.

So yes, I've done both. No need to get nasty.

"I don't think that's right. In PHP you get to set an absolute limit and once that limit is reached then it stops. You can not presume the database pooling was misconfigured, it probably worked just like the author intended."

Great, that's stupid. If the absolute limit for database connections is TWO, it should still not crash on the home page. My problem isn't the connection pooling, its the fact that a wasted database hit is being made for EVERY access to the home page. That's ridiculous. Especially on a site that has relatively static data (that doesn't change more often than once a minute.)

And trust me, I doubt ANY author would intend for their site to just "die." If that's how you intend to react to heavy load, you're just a bad author. That's isn't "premature optimization," it's obvious smart optimization.

Re:PHP != Crap Code

[killjoe]

"To say that you don't "need an IDE" is great. I can use vi to code my stuff to. The point is, it is NICE to have. "

Right. ANd PHP has IDEs. Stop putting this strawman up. There are IDEs for PHP. I happen to use and like Jedit.

"And, as I said before, good luck profiling a PHP app. Need to know which method is taking up most of your execution time? For all you know, one xml transformation can be accounting for 60% of your execution time... can you find that out in PHP? Sure, you can put in lots of time printouts that print to the screen or console but its certainly not as efficient as something like Eclipse Profiler."

Somehow during my years of programming in PHP I never needed it. Maybe that's because the combination of PHP and Apache is so lightweight. As I said I was averaging less then two percent CPU utilization taking 2 to 20 hits per second.

"Notice how all the stuff that I mentioned so far is free? Zend is $300 per license (and that's not the all-incompassing package)"

So? How much does intelliJ or Jbuilder cost? I am glad you are now changing your argument though. you went from "there are no PHP IDEs" to "PHP IDEs cost more then eclipse" at least we are making progress.

"Additionally, yes there real packages to back up my statements. Nothing out for PHP is as powerful as Hibernate, or as AspectJ, or as the profiler above or as JMS, or etc, etc..."

Let's presume you are right. So? Does any of that make PHP less scalable and if so by how much? That's the real question. Somehow my company was able to make millions of dollars per month without those things on a PHP based web site. Go figure!

"You might have been more productive in PHP. How much more productive? 10%? 50%? 80%? Is it enough to compensate for the possibility that you must rewrite if your application grows dramatically?"

I already said I was 200 to 300% more productive in PHP. And yes it was worth the price. Why? because it ended up that PHP was perfectly suitable for our application. WE NEVER HAD TO REWRITE IT. The application never got so big that it needed java.

"Great, that's stupid. If the absolute limit for database connections is TWO, it should still not crash on the home page. My problem isn't the connection pooling, its the fact that a wasted database hit is being made for EVERY access to the home page"

How is that the fault of PHP?

"And trust me, I doubt ANY author would intend for their site to just "die." If that's how you intend to react to heavy load, you're just a bad author. That's isn't "premature optimization," it's obvious smart optimization."

Premature optimization is writing your application in J2EE because you hope one day the application will need to be the size of amazon.com and taking two years to develop something that could have been on the market in six months.

Re:PHP != Crap Code

[NickV]

"Right. ANd PHP has IDEs. Stop putting this strawman up. There are IDEs for PHP. I happen to use and like Jedit."

Repeat after me. JEdit is NOT an IDE. In fact, JEdit doesn't even refer to itself as an IDE (it calls itself a "programmer's text editor.") You either don't know what an IDE is or have never used one. It's a text editor with syntax highlighting. Does it do autocomplete? No. Does it do debugging/tracing? No. Does it have integration with CVS or other source code management software? No. (Let me guess, you don't need that either!) Do you know what an IDE is?

"Somehow during my years of programming in PHP I never needed it. Maybe that's because the combination of PHP and Apache is so lightweight. As I said I was averaging less then two percent CPU utilization taking 2 to 20 hits per second."

It's NOT lightweight if you are doing complex things. There's more to load than CPU utilization. What about number of connections that your application spawns or uses? What about the number of threads it executes? Do you even know these answers?

So? How much does intelliJ or Jbuilder cost? I am glad you are now changing your argument though. you went from "there are no PHP IDEs" to "PHP IDEs cost more then eclipse" at least we are making progress.

THERE IS NOTHING OF THE CALIBER OF ZEND FOR FREE. Maybe you should read that again. So I'll be even CLEARER, there are no FREE PHP IDEs. (No your text editor that does color [which is wonderful what it does] doesn't count.) Eclipse is not only of the caliber of IntelliJ/Jbuilder but in many cases SUPERIOR. (In fact the latest version of JBuilder will just be plugins in Eclipse... Borland has even given up on making a full blown IDE because Eclipse is so good.) Not only do I say this, but so do many many other people in this topic thread.

Let's presume you are right. So? Does any of that make PHP less scalable and if so by how much? That's the real question. Somehow my company was able to make millions of dollars per month without those things on a PHP based web site. Go figure!

That's great! And you can write your application in assembler and if you're really good at assembler you can make a website that makes millions of dollars per month too! Oh hell, just write your own web server too... in Ada! Sure, why not? That's great too!

The point is these options exist and are written by professionals who probably know more about this stuff than you (just because you can't know more about everything than the experts in those fields.) I feel confident using software written by the Apache Group or the JBoss group... and you know what, I can write an entire database application without ANY SQL... and that's just great.

I already said I was 200 to 300% more productive in PHP. And yes it was worth the price. Why? because it ended up that PHP was perfectly suitable for our application. WE NEVER HAD TO REWRITE IT. The application never got so big that it needed java.

Ah... so you don't know Java. Ok... that makes more sense. I am like 30000000% more productive in English than in Thai.

How is that the fault of PHP?

Because you can't implement an in-memory caching solution in PHP without something like the Zend Optimizer since PHP spawns independent threads for each access of a page. Hell, without paying money for things like Zend Optimzer/ZendCache, PHP has to COMPILE THE BYTECODE ON EVERY HIT. But unless you use something like PEAR cache, you ain't getting in memory caches with PHP.

I know you've coded PHP, but it sounds like you don't really know how PHP works internally. But that doesn't matter becuase it's better!

Premature optimization is writing your application in J2EE because you hope one day the application will need to be the size of amazon.com and taking two years to develop something that could have been on the market in six months.

No. That's just hiring someone who doesn't know shit about the languag

Re:PHP != Crap Code

[killjoe]

"Repeat after me. JEdit is NOT an IDE. In fact, JEdit doesn't even refer to itself as an IDE (it calls itself a "programmer's text editor.") You either don't know what an IDE is or have never used one. It's a text editor with syntax highlighting. Does it do autocomplete? No. Does it do debugging/tracing? No. Does it have integration with CVS or other source code management software? No. (Let me guess, you don't need that either!) Do you know what an IDE is?
"

I never claimed that Jedit is an IDE for PHP. I simply said I used Jedit. There are IDEs for PHP though. More then one. Get that through your thick skull. Stop saying what you know is to be false. There are IDEs for PHP.

Having said that Yes Jedit integrates with CVS, yes it has code completion (depending on the language), and yes it integrates with various debuggers.

Finally IDEs have nothing to do with the scalibility of PHP.

"It's NOT lightweight if you are doing complex things. There's more to load than CPU utilization. What about number of connections that your application spawns or uses? What about the number of threads it executes? Do you even know these answers?"

I was doing complex things, as I said it was a very large and heavily used e-commerce site for a business with SOAP services, XML transforms, complex reporting etc. I was able to set how many connections it uses, how many applications it spaws all from either the apache configuration or PHP configuration. There was no threading, I was using apache1.3 with pre-forks. It worked like a charm and made millions of dollars a month.

"The point is these options exist and are written by professionals who probably know more about this stuff than you (just because you can't know more about everything than the experts in those fields.) I feel confident using software written by the Apache Group or the JBoss group... and you know what, I can write an entire database application without ANY SQL... and that's just great."

How does that make your application more scalable? I told you that my application scaled to 20 hits per second without breaking a sweat. I calculated that it could probably do 100 hits per second but we never even came close to that.

"Ah... so you don't know Java. Ok..."

I know java very well thank you.

"Because you can't implement an in-memory caching solution in PHP without something like the Zend Optimizer since PHP spawns independent threads for each access of a page. Hell, without paying money for things like Zend Optimzer/ZendCache, PHP has to COMPILE THE BYTECODE ON EVERY HIT. But unless you use something like PEAR cache, you ain't getting in memory caches with PHP."

Right, so what's your beef? You can get caching with PHP. Zend charges for theirs but there are free ones too. Hell I wrote one my self with a handful of code, it was easy!.

On the one hand you say PHP can't cache on the other hand you list products which enable PHP to cache. Where are you going with this?

This has got the most insane conversation I have ever had. How can you simultaniously claim that PHP is unable to cache and then list one free and one paid product that enable you to cache?

"No. That's just hiring someone who doesn't know shit about the language you're coding in. If you get an experienced java programmer that is used to a framework like Struts or Tapestry or JSF, they can easily output pages at a rate that is equal to or not faster than a professional PHP developer (I've done both professionally.) With PHP you are almost always starting from scratch (and rewriting (or cut and pasting) parameter validation code, authentication code/engines, connection pooling, etc)"

That's just a flat out lie. By the time you get your classpath figured out and your XML written the PHP application will be halfway to done. How? Just go visit the PEAR library and see for yourself.

"I don't mean an entire enterprise javabean application, i mean an application that uses the standard JDBC, and some messaging too."

That application will not be more scalable then PHP. The only time Java is more scalable then PHP is when you have to distribute your application server amongst multiple servers.

Re:PHP != Crap Code

[Anonymous Coward]

As to end the IDE part, Quanta fits the description quite well.

As regarding your argument, the only logical ending is one of you guys call the other an idiot :D

Re:PHP != Crap Code

[NickV]

Grr...

I never claimed that Jedit is an IDE for PHP. I simply said I used Jedit. There are IDEs for PHP though. More then one. Get that through your thick skull. Stop saying what you know is to be false. There are IDEs for PHP.

You said this in the previous thread, "Right. ANd PHP has IDEs. Stop putting this strawman up. There are IDEs for PHP. I happen to use and like Jedit." So you literally said, "There are IDEs for PHP. I like Jedit." Now maybe you didn't mean to imply that Jedit is an IDE, but it sure as hell sounded like it. (And JEdit's code complete is very basic... it can complete for loops, but it can't introspect packages for methods that are in the object [or maybe it now can, it couldn't a year ago])

Finally IDEs have nothing to do with the scalibility of PHP.

They do in terms of development.

How does that make your application more scalable? I told you that my application scaled to 20 hits per second without breaking a sweat. I calculated that it could probably do 100 hits per second but we never even came close to that.

They do in terms of development. I wasn't arguing performance scability at that point, I was arguing reinventing the wheel everytime (validating code, parameter check code, database connection pooling code, insert sql statements for object code, caching code.)


This has got the most insane conversation I have ever had. How can you simultaniously claim that PHP is unable to cache and then list one free and one paid product that enable you to cache?

Sorry... I assumed you knew what those products were. They're not parts of PHP (certainly memcached isn't... it's AN ENTIRELY SEPERATE DAEMON APPLICATION that can be used in ANY language.) They're other APPLICATIONS that you can use with PHP to store stuff in resident memory (since PHP can't DO THAT by itself without a bytecode compiler.) Your response is insane. It's like saying "Man, PHP can totally play Sam & Max because I can run SCUMMVM in Unix and Php runs in Unix too!"


That's just a flat out lie. By the time you get your classpath figured out and your XML written the PHP application will be halfway to done. How? Just go visit the PEAR library and see for yourself.
I know java very well thank you.

Ok you don't know Java. It takes about 1 second to resolve a class path in a modern development environment (like Eclipse). It takes about 1 minute to make an ANT build script that contains the line: "<classpath><pathelement path="${classpath}"/></classpath>"? How hard is it to copy your jars to the common/lib directory of tomcat or WEB-INF/lib directory of your webapp? You're telling me you can write half a PHP application faster than I can type "cp *.jar $TOMCAT_HOME/common/lib"? Shit, you are good.

Again, coding a little System.out.println("Hello World") application does not mean you know Java.

That application will not be more scalable then PHP. The only time Java is more scalable then PHP is when you have to distribute your application server amongst multiple servers.

It will certainly be more scalable than PHP without some bytecode optimizations or some inmemory cache products like memcached.

Re:PHP != Crap Code

[killjoe]

"There are IDEs for PHP. I like Jedit." Now maybe you didn't mean to imply that Jedit is an IDE, but it sure as hell sounded like it. (And JEdit's code complete is very basic... it can complete for loops, but it can't introspect packages for methods that are in the object [or maybe it now can, it couldn't a year ago"

First of all there was a reason I put a period between those two sentences. Once again (for the last time I hope). THERE ARE IDES FOR PHP. I use Jedit and used it for years for PHP development without ever once wishing I had something else.

"They do in terms of development'

There are IDEs for PHP.

"They do in terms of development. I wasn't arguing performance scability at that point, I was arguing reinventing the wheel everytime (validating code, parameter check code, database connection pooling code, insert sql statements for object code, caching code.)"

Wow. This is so stunningly weird I don't know what to say. None of that has anything to do with an IDE. None of it.

"Sorry... I assumed you knew what those products were. They're not parts of PHP (certainly memcached isn't... it's AN ENTIRELY SEPERATE DAEMON APPLICATION that can be used in ANY language.) They're other APPLICATIONS that you can use with PHP to store stuff in resident memory (since PHP can't DO THAT by itself without a bytecode compiler.) Your response is insane. It's like saying "Man, PHP can totally play Sam & Max because I can run SCUMMVM in Unix and Php runs in Unix too!""

Again weird. Jboss is a separate product, apache is a separate product, mod_jk is a separate product, hibernate is a separate product, eclipse is a separate product, resin is a separate product. What's your point again?

"It will certainly be more scalable than PHP without some bytecode optimizations or some inmemory cache products like memcached."

Bullshit.

OK, let's start from the beginning.

What is the upper limit of how large a PHP application can scale? I say a PHP application can easily handle 100 hits per second and can easily be divided to run on multiple web servers with session info stored in databases.

If you are writing an application that is going to handle 100 hits per second or less then use PHP. You will get a faster ROI from a PHP app.

Re:PHP != Crap Code

[NickV]

First of all there was a reason I put a period between those two sentences. Once again (for the last time I hope). THERE ARE IDES FOR PHP. I use Jedit and used it for years for PHP development without ever once wishing I had something else.

Fine... There IS ONE decent commercial IDE for PHP. And even with periods, you have flow in English sentences. Like "The dog is small. I like terriers" makes more sense and is more logical than "The dog is small. I like cheese."

There are IDEs for PHP.

Fine... one decent commercial for pay IDE.

Wow. This is so stunningly weird I don't know what to say. None of that has anything to do with an IDE. None of it.

You're having a hard time following my logic. I am arguing two things in this thread. One is performance scalability and one is developmental scalability. In that block above, I argue that having tons of prewritten libraries made by professionals that provide scaffolding/framework functionality means you don't have to reinvent the wheel everytime you write a new application. This leads to faster development. This type of scaffolding framework is not really found for PHP (and the closest you can get is Drupal which isn't that close.) It relates to the IDE because BOTH lead to more productive development. Understand now?

Again weird. Jboss is a separate product, apache is a separate product, mod_jk is a separate product, hibernate is a separate product, eclipse is a separate product, resin is a separate product. What's your point again?

JBoss is written in Java. Apache has nothing to do with Java, it's a web server. Hibernate is written in Java. Eclipse is written in Java. Resin is written in Java. (I'll give you mod_jk since it's an apache plugin its written in C) Zend Optimizer is written in... C. Memcached is written in... C. All of the PHP caching solutions are written in... C. See? Get my point now? In case you don't, it's that PHP isn't capable of doing this by itself... Java is. If you are using PHP you need to use OTHER technology in addition to PHP to make caching work.

What is the upper limit of how large a PHP application can scale? I say a PHP application can easily handle 100 hits per second and can easily be divided to run on multiple web servers with session info stored in databases.

Great! So now your session data is stored in a DB, so if you have a busy site, you are getting a minimum of n number of hits to the database where n = number of hits to the site. That's your BASE LINE now. You are ALWAYS going to have a DB hit per page access at MINIMUM.

You don't see how that's a problem? That if you scale the actual web server boxes up, you can't really scale the Database? You add two more machines to handle twice the extra load, but now your database is hit twice as hard. This is why you always see PHP sites go down with mysql connection errors btw.


If you are writing an application that is going to handle 100 hits per second or less then use PHP. You will get a faster ROI from a PHP app.


At least you stopped claiming you know Java. Your fundamental argument for PHP this whole thread has been "YO! I wrote a site that does a bagillion dollars of sales in a month in PHP. And it was faster than writing it in [random_language] because I say so and I feel that way"

Face it, YOU personally believe PHP gives you better ROI. I can argue to the moon that the advantages Java provides. Things like never ever ever having to write sql, worry about transactional code, transparent persistence layers, model-view-controller frameworks which provide auto validation and auto type casting ( For example: you can make an option pull down form and populate it with objects not strings, and when a user selects an item on the form the actual object is returned to the application, not a string you have to manually verify and then use as a key to reload the object), database connection pools, great web services layers, etc.

Re:PHP != Crap Code

[NickV]

You don't see how that's a problem? That if you scale the actual web server boxes up, you can't really scale the Database? You add two more machines to handle twice the extra load, but now your database is hit twice as hard. This is why you always see PHP sites go down with mysql connection errors btw.

Before I get jumped on by anyone else still reading this ridiculous thread (which has to soon be going for some record.) I know you can get around this problem too through different ways. None are cheap though (You can't do funky network topology changes with DNS to both machines doing a load balance because then you get an inconsistent state between the boxes.) You can, however, get yourself a clustering database, like Oracle 10g or IBM's DB2. Of course, neither are cheap (nor easy to use.)

In the end, this thread is about preference of language. Productivity from language use by itself doesn't really mean much, it just means you're more comfortable in a language. This guy knows PHP better, hence, of course, he prefers it.

It's very similar to writing a research report... you can write it in whatever language you're most comfortable in and be the most productive, but if your best language is Bangladeshi, you'll be spending more time finding references for your paper than if its in English. Same rationale in java/php debate.

Re:PHP != Crap Code

[killjoe]

"Fine... one decent commercial for pay IDE."

Nope look further. There are more then one.

Having said that I am glad you finally admitted you were wrong on that.

"If you are using PHP you need to use OTHER technology in addition to PHP to make caching work."

Most people run apache (written in C) and mod_jk (also written in C). Again though it doesn't matter. You have now admitted that your original assertion about caching was wrong. A PHP application does have the ability to cache.

"You don't see how that's a problem? That if you scale the actual web server boxes up, you can't really scale the Database?"

The scalibility of the database is always the arbiter of the scalibity of your application. That's true of any language. If your database can't scale then you might as well pack it in.

Having said that I was able to take 2 to 20 hits per second without storing my session in the database and without multiple web servers. One server, one database that's it.

"Face it, YOU personally believe PHP gives you better ROI."

Well yes, I have experience with both and that's my experience.

I am now going to ask you once again the question you refuse to answer.

How big can a PHP application scale up? That's the thread topic here.

Re:PHP != Crap Code

[NickV]

Nope look further. There are more then one.

Having said that I am glad you finally admitted you were wrong on that.

No, you misread me. There are NO free IDEs for PHP that are any good. I assume you now think Jedit isn't an IDE anymore... good. What is out there? PHPEclipse? It's not even supported by the authors anymore. Quanta? Again, nothing more pretty much than syntax highlighting.

There's ONE ide for PHP that's worth anything, and it costs $300 starting.

Most people run apache (written in C) and mod_jk (also written in C). Again though it doesn't matter. You have now admitted that your original assertion about caching was wrong. A PHP application does have the ability to cache.

What? No I didn't. Most people run their web applications in a Java container... in fact they have to. Tomcat, JBoss, Weblogic...all Java. Jesus Christ, next thing you'll start telling me that PHP can manipulate registers directly because it runs Unix and everyone runs Unix and Unix has kernel assembler in it!

The fact is PHP can't do Caching.. it CAN'T. CAN NOT. You need to use something NOT written in php. You have to use an application that has NOTHING to do with PHP (other than PHP can use it.)

Jeez... are you going to start saying "Well PHP can fdisk hard drives because it runs on an ext2 partition for most people and that means PHP can call system('fdisk') and fdisk too, so it's EXACTLY like C!" No, it's not. Calling external programs and relying on external programs creates extra dependencies on things written in other languages. These are needed because PHP can't do it.

The scalibility of the database is always the arbiter of the scalibity of your application. That's true of any language. If your database can't scale then you might as well pack it in.

Having said that I was able to take 2 to 20 hits per second without storing my session in the database and without multiple web servers. One server, one database that's it.

Ok to part one. Right. THAT IS WHY YOU MINIMIZE DATABASE ACCESS. That is why I've been arguing about caching this whole time. You need to use the database smartly, not hit it everytime somebody accesses the home page just for their first name.

Obviously if you don't store the session in the db that's ok... where do you store it? Do you know? Do you actually know internally what php does for sessions that are not db backed? I'll let you look that one up, I'm sick of giving you real information everytime I respond.

What you responded to was the fact that I said earlier you can't scale a PHP application across multple web servers because then you NEED to store your session in a DB... and guess what? Then you're fucked.

Well yes, I have experience with both and that's my experience.

I am now going to ask you once again the question you refuse to answer.

How big can a PHP application scale up? That's the thread topic here.

I'm not answering because its a stupid question. The answer of course is "It depends" I said that like 10 messages ago. If your PHP application says "Hello World" it's going to scale better than an enterprise portal that collates data from 20 independent sources. The need for scability is also dependent on your audience. If your running a single threaded application that is going to have an audience of two, do whatever the fuck you want. (btw, this has NOTHING to do with the ROI of java vs php.)

And your java experience must be awesome considering you basically admitted to not even knowing how to set a classpath (your "I'd have half the application done by the time you've set your classpath and xml files" comment) So don't talk to me about your "experience" in both. Learn how to set a classpath and then come back and talk to me.

Re:PHP != Crap Code

[killjoe]

"ou need to use something NOT written in php. You have to use an application that has NOTHING to do with PHP (other than PHP can use it.)"

Right. A PHP application can cache. Thanks for admitting that you were wrong again.

"That is why I've been arguing about caching this whole time. You need to use the database smartly, not hit it everytime somebody accesses the home page just for their first name."

Right, and you have also admitted that PHP applications can cache.

"Obviously if you don't store the session in the db that's ok... where do you store it? Do you know? Do you actually know internally what php does for sessions that are not db backed? I'll let you look that one up, I'm sick of giving you real information everytime I respond."

Either on disk or in memory, depends on how you wrote the application. I stored my on disk which was fine because I was only running on one machine.

"I'm not answering because its a stupid question. "

Really? You started this whole thread by stating that PHP applications don't scale. Now you refuse to state how far up they can scale.

"And your java experience must be awesome considering you basically admitted to not even knowing how to set a classpath (your "I'd have half the application done by the time you've set your classpath and xml files" comment)"

Once again. By the time you set your classpath and written your XML descriptors a good PHP programmer would be halfway to done.

Re:PHP != Crap Code

[NickV]

Right. A PHP application can cache. Thanks for admitting that you were wrong again.

A PHP application by itself can not cache. There is a big difference between writing your application so that it can use an external program as its "cache" and having something that is implemented in the language and can be set transparently.

It's alot harder to use something like memcached after the fact in PHP (since you have to add external calls to it EVERYWHERE) than it is to just chagne one line in an XML file to turn on a cache. To turn on caching in most modern Java frameworks, you literally have to drop ONE line into your application (like: hibernate.cache.provider_class=net.sf.ehcache.hibe rnate.Provider) vs the massive system wide change you'd have to make in a PHP application.

Additionally, you have to make EXTERNAL calls to an application running as a seperate daemon/process on your system. Not only is there a performance penalty in doing that (a pretty hefty one too if you're using something older than PHP 5), but it also means you're dependent on an outside process.

You don't see the problems with that? You don't see how php making external system calls is not exactly the best way? What if you need to debug the memory caching itself, or see how the caching is evicting objects, or profile the cache? How good is your C? Better be good or you're fucked.

By your logic, you can write a file system driver in PHP. Or a 3D first person shooter. Sure, you can make system calls to your hearts content, but you're an idiot if you do that.

Right, and you have also admitted that PHP applications can cache.

Except they can't cache across multiple servers/instances. How do you keep them in sync? Especially when the cache (as mentioned above) is a completely seperate process. How is PHP on box A going to tell cache written in C on box B that stuff has changed?

I know, you can hack up some code that does it. Great! More code that you have to write instead of using something that already exists. By the time you write that up, I'll be done for a week. And unlike your bullshit about classpaths, I do believe I can edit an XML file and add one line faster than you can write a syncing caching solution.

Maybe you can sit in the server room and run between them.

Really? You started this whole thread by stating that PHP applications don't scale. Now you refuse to state how far up they can scale.

Because that question depends on millions of variables. There's a big difference between me saying "In some cases PHP does not scale" and you asking for a specific number. I'll tell you right now, as I said about 30 times before, if you're doing something like collating numerous (10,20+) datafeeds (external/internal) that are customized for thousands of users, you'd be a fool to do it in PHP. If you're doing a little application that says "Hello, Nick!" then go ahead and do it in php.

I mean, I don't get it... do you want a simple number? You seem to think this is a simple question. How about 42? Is that a good answer?

Or are you looking for reassurement? Yes... your application does seem to be ok in php. Yes, you are ok doing what you did in php since it can't break... :pats head:

Once again. By the time you set your classpath and written your XML descriptors a good PHP programmer would be halfway to done.

It takes 4 seconds. Literally. I just timed how long it took to type "cp ~/jars/*.jar WEB-INF/lib". The XML files are pregenerated, and you must be pretty slow if you can't type in a directory path in the part of the file that says "INSERT-WEBAPP-PATH-HERE"

Of course the XML files can get complicated, but that's because of the ridiculous power you have in them. Want to change your entire authentication scheme? Edit one line in an xml file and you're done. Enable caching, add one line (like I mentioned above) and you're done. No need for massive global c

Re:PHP != Crap Code

[killjoe]

"A PHP application by itself can not cache. There is a big difference between writing your application so that it can use an external program as its "cache" and having something that is implemented in the language and can be set transparently."

And yet the end result is that a PHP application can cache. Strange how that works out huh?

"Additionally, you have to make EXTERNAL calls to an application running as a seperate daemon/process on your system. Not only is there a performance penalty in doing that (a pretty hefty one too if you're using something older than PHP 5), but it also means you're dependent on an outside process."

You mean as opposed to RMI, JMI and other socket based protocols right?

"Except they can't cache across multiple servers/instances."

Right. I already said that the only time Java will scale larger then php is when you spread your application across multiple servers. Since PHP can already store session data on shared storage or a database that's the only point at which java is more scalable. Up to that point PHP is as fast if not faster then java.

"Because that question depends on millions of variables. There's a big difference between me saying "In some cases PHP does not scale" and you asking for a specific number"

So you were full of shit when you said PHP can't scale. What you meant to say is that the choice of platform is just one of a million different variables which may get in the way of the scalibility of your application.

"I'll tell you right now, as I said about 30 times before, if you're doing something like collating numerous (10,20+) datafeeds (external/internal) that are customized for thousands of users, you'd be a fool to do it in PHP."

Why? Is it because "php doesn't have an IDE" or is it because "PHP can't cache". I don't think I will take your opinion on this. So please do tell us why it's not possible for PHP to handle more then 20 datafeeds that are customized for thousands of users. Exactly what about PHP prevents you from cutomizing feeds?

"So yea... go away "pro." Come back when you educate yourself about BOTH technologies instead of obviously blindly arguing one."

You made the assertion that PHP applications don't scale. I am still waiting for you to tell me at which point PHP applications fall down. That way we can both agree that any point below that line PHP is just as good if not better then Java.

Extreme Programming at Wikipedia

[jfroot]

Wikipedia explains what Extreme Programming is at:

http://en.wikipedia.org/wiki/Extreme_Programming

Re:Extreme Programming at Wikipedia

[rolfwind]

I brushed against Xtreme programming a couple of years ago - what's the difference between that and bottom-up design, with more customer feedback?

(BTW, I'm asking because I tend to be wary of the latest buzzwords in the industry, because they obscure the legitimate breakthroughs.)

Re:Extreme Programming at Wikipedia

[dubl-u]

It has a nubmber of additional practices. The most important are probably test-driven development, refactoring, regular iterations (ideally, one week) and frequent releases.

Re:Extreme Programming at Wikipedia

[rolfwind]

Sounds like that mindset can go hand in hand with Lisp:)

http://paulgraham.com/lisp.html

Do Xtremers have any particular choice of language?

Re:Extreme Programming at Wikipedia

[dubl-u]

Do Xtremers have any particular choice of language?

I think the short answer is no.

A lot of the original XP people have a background in Smalltalk, but from the mailing list and talking to people at the conferences, there are few people doing current work in that. Java and C# are probably most common, but that generally seems to be a business decision, not a technical one. I hear a lot of excitement about Python and Ruby, too, both of which Paul Graham recommends as reasonable Lisp alternatives.

Personally, I do most of my work in Java, both for business reasons and because of the good tool support. Automated refactoring tools like IntelliJ's IDEA make a refactoring-driven approach to design much more workable. But I'm hoping that Ruby continues to grow in both library and tool support.

Marketing

[gunpowda]

Gallery 2.0 is the natural successor to Gallery 1...

Of course, it were a Microsoft product, the natural successor would be 'Gallery Super Uber Ultimate Edition'.

Re:Marketing

[mblase]

Of course, it were a Microsoft product, the natural successor would be 'Gallery Super Uber Ultimate Edition'.

You sure you're not thinking of the "Street Fighter" series?

Re:Marketing

[Pneuma ROCKS]

How about 'Vista Gallery'? Oh, wait...

Re:Marketing

[Anonymous Coward]

hahahaha...... wooohooo.... whew!.... man.... sorry..... trying to stop laughing. heeheehee. ok. think i've got it under control now. man, you anti-microsoft guys. you really know how to make me laugh. you should work in stand-up. at the very least, you should keep up the good work getting those anti-m$ feelings stirred up out there. i mean, it's such an-under represented viewpoint...especially in places like /.

Re:Marketing

[bhiestand]

Of course, it were a Microsoft product, the natural successor would be 'Gallery Super Uber Ultimate Edition'.
The shorthand of that would be Microsoft Gallery 2004.

Re:Marketing

[erlenic]

And the current release estimate would be Fall 2006.

buzzwords check passed

[tonigonenstein]

OOP, extreme programming, test driven development, MVC, factories, modularity

Re:buzzwords check passed

[DiarmuidBourke]

OOP: pass
extreme programming: pass
test driven development: pass
MVC: pass
factories: pass
modularity: pass /.'ing: fail

Re:buzzwords check passed

[DiarmuidBourke]

Theres a line break after "modularity: pass" and before "/.'ing: fail".
*I must learn to use the preview button*.

Re:buzzwords check passed

[drew]

Nope, sorry, they forgot XML and Object-Relational Impedance Mismatch.

Not bad, but I'm sure with a little more work they could throw at least half a dozen other nearly meaningless phrases in there.

Re:buzzwords check passed

[grimJester]

OOP, extreme programming, test driven development, MVC, factories, modularity

I'd say the list is all common sense with the notable exceptions of extreme programming and test-driven development. It would be interesting to know how that worked out, specifically what kind of problems there were.

Re:buzzwords check passed

[bhiestand]

Theres a line break after "modularity: pass" and before "/.'ing: fail".

No, there isn't. That was the problem.

What the fuck is Gallery

[mrpotato]

Why should I care more about how it was developped than what's the end product?

Announcing some software based on what process was used isn't informative at all.

Re:What the fuck is Gallery

[cnettel]

This is news for NERDS, stuff that MATTERS. The code license and development approach are far more important than the results.

Slashdotted

[xot]

here is the google cache link :
http://66.102.7.104/search?q=cache:EYRwD7JSrCoJ:ga llery.menalto.com/+&hl=en

Re:Slashdotted

[trompete]

Please use the SourceForge link below people. The Gallery forums aren't working either because the site is being owned.

Gallery 2

I have a gallery2 site too. It'l be nice when I can get enough bandwidth to get the full version of gallery2 :(

Site (With default theme and ~500 pics): here

Re:Well, that's lovely but...

[Anonymous Coward]

Get a clue nitwit. Upload the binaries to a location under your account that apache can access and chmod them to 755. Then tell Gallery where they are at.

NOWW!!!!!!!

[Anonymous Coward]

"Don't wait, download Gallery 2 now!" For the sake of all that is good and holy DOWNLAOD IT NOW!!!!! You must not delay another second! Stop reading and slashdot the web server!!!!

Re:NOWW!!!!!!!

[kahanamoku]

Or don't slash dot the web server, and try slashdot the CVS server!

$ cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/gallery login
$ cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/gallery co gallery2

Or for those with it already installed,

$ cd gallery2
$ cvs update -Pd

Ran the update the other night, having just installed it a week ago, and to my suprise I was blessed with v2.0 (possibly one of the first to get it because they were yet to advertise the release on their site)

Nope, Not offtopic!! Re:What the fuck is Gallery

[redwoodtree]

This is not offtopic at all. I'm sitting here trying to get to the site, it's /.'ed and though I was able to get it to load without the images, all it talked about was the different versions and its development.

Doing a quick google search for gallery 1.0 or 2.0 leads to nothing immediately informative.

So, what the fuck is gallery!?

How are the Debian packages?

[swillden]

Hey, has anyone tried out the Debian gallery2 package? Does it do a good job of migrating the data, or does it install stand-beside? I have a gallery 1 installation that my whole family uses, and I'd like to know if it's safe to upgrade, or if I should wait for the bugs to be worked out.

Re:How are the Debian packages?

[h0bbel]

as far as I know, it installs it besides G1 and you then use the G1->G2 migration module to import your existing install.

Re:How are the Debian packages?

[Scooter]

..and it doesn't modify your old Gallery install/data, so you have nothing to lose. It did mine without a hitch!

Re:How are the Debian packages?

[BacOs]

I'm the Debian package maintainer for both gallery1 and gallery2. The gallery2 package is completely separate from the gallery1 package - you can install/use both simultaneously if you wish. Using the gallery2 migration module, you can migrate from Gallery 1 to Gallery2.

FWIW, I uploaded version 2.0-1 of the Debian gallery2 package this afternoon - it should be available in Debian unstable as of this afternoon's archive run.

Re:How are the Debian packages?

[swillden]

Thanks for your excellent work! I just installed gallery2 (from testing, so I'm still using the RC) and it's working very well. The migration just finished and it looks great.

Buzzwords

[Monx]

Oooh. Buzzword compliance is the first thing I look for in photo management software.

Re:uhh ohh

[msaver]

Yeah -- but it uses OOP! *cutting edge technology* It sound awesome... orienting objects and whatnot.

But my favorite part is the bit about "test driven development." Of course it's test-driven... that's how programming generally works.

And Zonk... please tell me what the program is before telling me to "Clickey here! Download Now!". I'm not really looking for online photo management software at the moment, thank you.

Big deal.

[oGMo]

From a developers point of view, the Gallery 2 framework is particularly interesting because it's written with modern programming patterns (OOP, extreme programming, test driven development, MVC, factories, modularity, ...) in mind

How is this interesting? So you've got the toys and the buzzwords. Does it solve a problem? This doesn't say a word about macrodesign. Is the overall model elegant? That's the important part. The rest are just some really nice hammers and screwdrivers. They don't automatically make a good building.

which is rather unusual for PHP based projects.

So is this the interesting bit? "We made something that uses a lot of modern stuff, we did it in PHP, and it took us 3 years". Big deal?

Over 1500 unit tests ensure correct functionality

Ah unit tests. First off, 1500 isn't very many. Secondly, as much as I love them, they only test what you thought of. They're a great tool, but they don't ensure correct anything: they just make sure that when you add something, you don't break something else. As long as you thought of "something else".

and its architecture is really impressive.

That's nice. How?

Re:Big deal.

[g0sub]

No no no - the _other_ foot. You were supposed to get up on the _other_ foot.

I've just finished creating the worlds first working fusion reactor, but hey, whats the fuzz - others have thought of it before me.

Re:Big deal.

[Anonymous Coward]

you're a dick.

Re:Big deal.

[Tassach]

I've been using gallery for a while to manage my family photo album. For a vanity site like mine, it's massive overkill; and from what I've seen, it really doesn't scale very well on the high end.

This past weekend I cranked out a 66 line bash script that reproduces about 90% of the functionality from Gallery that I actually use. If I really feel I need the other 10% I'll do a little more hacking.

Re:Big deal.

[DataPath]

unit tests don't just show that your program works, they show that your program STILL works (make great regression tests)

Re:Big deal.

[oGMo]

I've just finished creating the worlds first working fusion reactor, but hey, whats the fuzz - others have thought of it before me.

So you think an app that maintains a photo gallery is something that hasn't been done a few times? Possibly on every known platform, in every known language, for every known format, both offline and online?

But I see how one might confuse it with a technological breakthrough on the order of a new energy source.

Re:Big deal.

[Titanium Angel]

It is true that Gallery 1 doesn't scale well, but this isn't so with G2. It has been designed with scalability in mind, so it should theoretically scale to millions of images. The largest I've seen myself is used by an image hosting company, and there are a little less than a million pictures in it, and it still works beautifully. You can read an in-depth comparison of Gallery 1 and 2 on this page.

Re:Big deal.

[oGMo]

Precisely. This is very helpful. Everyone should do it. But they should do it knowing what they represent. (It should go without saying that you need to write good tests, and if you forget to test something, you're not covered.)

Re:Big deal.

[g0sub]

Hehe, but it is, it is I tell ya.

While I agree with you that Gallery 2 is hardly groundbreaking, I find your bashing a bit harsh. Some people, maybe you're one of them, have a tendency to always try to find whatever is wrong with everything. To the extent that it seems like Gallery has hurt you in the past or something.

Unit Test 1501

[TimCrider]

Slashdot Effect [ FAILED ]

Re:Nope, Not offtopic!! Re:What the fuck is Galler

[Ford Prefect]

Try the second sentence of the article summary?

Re:Nope, Not offtopic!! Re:What the fuck is Galler

[Anonymous Coward]

There is a, admittedly very obscure, reference to Gallery being "the best online photo management product possible" hidden in the article.

What could it be? Hmmm, let's see...yeah! It's really the code-name for the beta release of Duke Nukem Forever! :rolleyes:

Re:paid press release on /.?

[WilliamSChips]

Dammit, stop teasing me with the release of phpBB3...

Aye, this is what the buzzwords are for

[Mateo_LeFou]

I've done the what-ever-it-takes-to-get-something-online style PHP work for a year or so now, and have always wanted a mature, nicely-designed codebase to look at (NOT osCommerce!)

I think it's be good for intermediate PHP developers to know that Gallery2 is ... whatcha call it .. "real software"

Re:Aye, this is what the buzzwords are for

[Anonymous Coward]

osCommerce... what a steaming pile of dog shit. I have to give it some credit, (there are thousands of online stored based off it), but my first hand experience ... it is horribly broken in so many ways.

Can it manage photos of your server on fire?

[joelparker]

Anyone have a cache or alternate download page?

JAlbum vs InAlbum ???

[Anonymous Coward]

I love InAlbum http://www.inalbum.com/ !

Not from my experience

[lullabud]

I've been using G2 since beta 2. There were 4 beta's and an RC, iirc. I've never seen anything like spam redirections, but then, I wasn't accessing it from Windows... =P G2 is great.

Re:Not from my experience

[uss_valiant]

G2 has nothing like spam redirects or such things built-in. Search the source...
Users who have reported "weird" redirects (you may be the third), always had a misconfigured webserver, which made their Firefox use the built-in (FF) google "I feel lucky" feature. So if you give your webserver a weird name and misconfigure the webserver, you end up on a I feel lucky hit from google for that search term.

Working download link

[Karamchand]

Since the gallery.menalto-site seems to be slashdotted already here's a working download link at least, directly from sourceforge.net: gallery 2.0 file list

the new site runs Drupal

[bkessels]

For those interested. Gallery is the next big one in line to move its site to drupal

Re:the new site runs Drupal

[bkessels]

well, i /meant/ to say: "/was/ the next big site", since obviously, it already moved. But /. does not let me change my comments, so it seems. (Drupal does)

Re:the new site runs Drupal

[lophophore]

Yeah. And it is working fabulously...

Talk about borked. ouch.

Re:the new site runs Drupal

[Anonymous Coward]

I'm guessing that (a) they did not turn on Drupal's cache or (b) they did not turn on MySQL's query cache.

Re:the new site runs Drupal

[Anonymous Coward]

I'm guessing that (c) Drupal's a piece of crap.

Re:the new site runs Drupal

[bkessels]

It is what they call 'the slashdot effect' :p Normally Drupal (if properly configured) can handle these peak loads very well. But without cache or throttle settings you might get in trouble with such a peak. Or your servers might just collapse under the load, off course.

Re:the new site runs Drupal

[bkessels]

uhu. back that up with some examples please. making such a statement says more about what you are. I'm guessing that (d) you are a moron that has never sen or used Drupal. And (e) hope to never see you appear in the drupal community.

Re:uhh ohh

[Sinus0idal]

Hmmm gallery, what COULD it be.

Re:uhh ohh

[vmardian]

But my favorite part is the bit about "test driven development." Of course it's test-driven... that's how programming generally works.

Test driven development means the unit test is written at the same time as the feature is written, or sometimes even before the feature is written.

Database required? Are you nuts?

[Matt Perry]

From the requirements page:

Database (Gallery 2 only) - MySQL 3.x or 4.x, PostgreSQL 7.x, Oracle 9i or 10g (Gallery 1.x does NOT require a database)

Are you fucking kidding me? A database is required? Not optional if you don't want a few features, but required? I have to create another database user with yet another password just to display some pictures with thumbnails? Since I'd be using Gallery 1 because of this ridiculous requirement I have to ask, is Gallery 1 going to continue to be supported?

Re:Database required? Are you nuts?

[h0bbel]

Yes, Gallery 1 is still supported and under further development.

top three favorite features

[jackstack]

1. Upload a huge honking zip file of compressed images and create an album
2. Integrated "Publish to Your-Special-Gallery" from WindowsXP "My Pictures" folder
3. Easy to customize permissions

This (along with gnump3d) are my two FAVORITE web apps for linux.

Re:top three favorite features

[stevey]

It is always nice to see more gnump3d users around :)

A new release came out earlier this week - upgrade now if you've not done so already ..

Gallery Local, a smart client for Gallery

[anglete]

Try out Gallery Local, a smart client for gallery.

It allows viewing of your gallery offline. It takes advantage of the new XML-RPC routines available in Gallery 2.

Re:Gallery Local, a smart client for Gallery

[NardofDoom]

For you Mac users out there, here's an iPhoto plugin that allows you to export photos directly to your gallery and create albums.

Darnet!!!

[Praedon]

Stop Slashdotting the server so I can download something! : )

My Gallery

[jelevy01]

If anyone cares here is my gallery: http://pics.jeremylevy.com/

Re:My Gallery

[jelevy01]

Hmm, on second thought, posting a link to my gallery on slashdot might not have been the smartest thing i've done today...

Re:My Gallery

[Anonymous Coward]

pwn3d!!

oh crap, i posted mine also

Re:My Gallery

[Anonymous Coward]

I found your "secret" folder by the way. You might want to put a password on those pictures of your tiny cock.

Re:My Gallery

[Anonymous Coward]

Album: New Years 2003

girl in red shirt....

roowwwwrrr

Karma Whoring at Wikipedia

[Anonymous Coward]

Wikipedia explains what Karma Whoring is at:

http://en.wikipedia.org/wiki/Karma_whoring

Re:Well, that's lovely but...

[Anonymous Coward]

Check your facts dipstick, in general the binaries you need aren't easy tome come by. If you want to dispute that, show me the link.

Upgrading?

[MrP-(at work)]

I run Gallery 1.x on my site. Since the gallery site is currently slashdotted, does anyone know if its easy to upgrade from 1.x to 2.x or should I just stick with 1.x (which seems to suit my needs just fine as it is)

In case it makes a difference: My gallery is on a hosting providers server, not my own. I have SSH access though.

Re:Upgrading?

[BacOs]

Gallery 2 has a migration module that allows you to import pictures from Gallery 1 into Gallery 2.

Re:Upgrading?

[Zerbey]

It's easy as pie, but can take a while depending on the size of your gallery and speed of the server (took about 15 minutes for my creaky old dual PIIIs to convert several thousand pictures). I did this in one of the early betas and it worked absolutely fine so you should be fine!

Re:Upgrading?

[frostw]

I have a Gallery 1 setup, and am trying to upgrade.

When I choose "Import Gallery 1", it finds my old albums, tells me what it is going to import and then when I click go it says "Importing Photos" with the name of the first album. Nothing happens after that.

Bugger

ZE == Crap Runtime

[Anonymous Coward]

PHP is slow as shit, it's not the right tool for large projects. PHP5 adds some language improvements and 5.1 improves on speed a little (function call overhead is now acceptable) but APC still isn't working! Devs should be targetting bytecode for a third party JITable VM with PHP6, not just adding native unicode support.

Well it didn't start off as a rant but the gallery site is dead, that's what happens when you get a few thousand requests making shitloads of database queries from a bloated runtime. Gallery, "it's got all the right buzzwords but dies under load", great engineering job guys, now go lookup what caching is all about.

I'm not really this much of an asshole, honest. Check out luajit if you haven't already.

Re:Well, that's lovely but...

[Anonymous Coward]

Use your head and ask some questions. You can then turn left or right and get away from that brick wall you keep bumping your head into.

http://sourceforge.net/project/showfiles.php?group _id=7130&package_id=14464

http://www.google.com/search?hl=en&q=jhead&btnG=Go ogle+Search

http://www.google.com/search?hl=en&lr=&q=imagemagi ck&btnG=Search

And if it were a Java Product...

[Anonymous Coward]

...it would be called Gallery 5!

3 years? I think not.

[Anonymous Coward]

You spent those three years figuring out what you wanted to make.

Admit I have no idea about the scope of this project (didn't rtfa), but i'm sure a couple of guys could whip up something similar in a month of their spare time.

Re:3 years? I think not.

[Anonymous Coward]

> Admit I have no idea about the scope of this project *
> ****(didn't rtfa)******, but i'm sure a couple of guys could
> whip up something similar in a month of their spare time.

Did it ever occur to you (of course not) that maybe if you read tfa, you'd avoid making a total blithering fool of yourself? Novel concept, I know.

Re:3 years? I think not.

[Tidal Flame]

I can't access the site or I would RTFA, but I'm going to have to agree... PHP is really easy. I've coded things that are probably bigger and more complex than this by myself. Obviously they weren't perfect, but according to other commenters, neither is this... it would seem that the security might not be very good, and that the error handling is particularly bad.

Give me a break.

[saberworks]

If this is an example of good PHP coding someone please shoot me. They use their own internal "require_once" instead of simply using ini_set to set the include directories correctly. They name all their included files *.inc and *.class which can be a severe security issue if these files are available from the web root (which by default they are).

From the code I saw, everything is extremely over-engineered (read: too freaking complicated). It looks like they have some input sanitization functions but they aren't used consistently.

The coding style throughout isn't consistent (but who cares?).

On the plus side, they have used PHPDOC or some similar syntax to document their classes and functions (makes for good API docs). They have used external libraries for some things like templating and database abstraction (can't say much for their choices but at least they didn't rewrite those from scratch).

The error handling also looks particularly nightmarish:

if ($ret->isError()) {
return array($ret->wrap(__FILE__, __LINE__), null);
}

(repeated 12 times in one 100 line file!!!!)

Re:Give me a break.

[Warren_Canuck]

About the internal "require_once", maybe you should read the comments on it then you would see that G2 keeping track of what files it has already included and only using PHP's (very slow) require_once speeds up the function by about 10x (line 2480, modules/core/classes/GaleeryCoreApi.class)

As for the coding style not being constistent, could you please give an example? G2 has very strict code style guidelines that have to be followed for a patch to be accepted (you can find them on the g2 codex site which is currently getting hammered). The code may appear complicated but if you take the time to read things it's actually quite legible and it makes sense. Usually people who have not worked on very large team projects feel intimidated by something as large and complex as Gallery2, I know I was when I first started working on it.

I admit the .inc and .class issue appears to be somewhat concerning, nothing that can't be fixed by 2 lines in a .htaccess file though. I'll be sure to bring it up at the next meeting.

The error handling code works and I challenge you to find a cleaner way to let the developer know exactly where an error occured so they can fix it. Why does it occur so often? Because error checking is good, it's just too bad more people don't do it.

Re:Give me a break.

[Fweeky]

"The error handling code works and I challenge you to find a cleaner way to let the developer know exactly where an error occured so they can fix it."

I'll take "exceptions" for £50, Bob. Unfortunate that PHP5 doesn't seem to be taking off quite like PHP4 did; I wonder if that's because many of the people who would find the new new features attractive are finding other languages suit them better? I know I did, and I used to really love PHP and was dead excited by Zend Engine 2 :/

Re:Give me a break.

[Warren_Canuck]

I'll take 'exisiting installbase' for $100, Bob. The installbase of PHP5 is NOWHERE as near as PHP4 right now and since most of our users don't run their own servers but instead rely on webhosting companies, PHP5 isn't really an option. I agree, PHP5 has a ton of great features and I'm sure they would help greatly with Gallery2 but we simply can't switch to it or we'd be preventing what would amount to probably 90% of our userbase from upgrading to it.

Re:Give me a break.

[Gnulix]

They name all their included files *.inc and *.class which can be a severe security issue if these files are available from the web root (which by default they are).

What do you propse they name their files? And how is another name standard supposed to help increase security?

I would say that this should the responsibility of the server, rather than the application writers. Distros shouldn't have insane defaults, that allow downloading of all kinds of files...

Re:Give me a break.

[Anonymous Coward]

"What do you propse they name their files?"

Err... ".php"?

This is not the "application writers fault" why should they fix somthing thats not broken, everyone else can manage to name there files correctly (.php).

Re:Give me a break.

[Buddha443556]

"... most of our users don't run their own servers but instead rely on webhosting companies, ..."

Still doesn't seem very shared server friendly with 6+ MB in module/core and 1.5 MB in module/core/classes. Shared hosts get interested in processes that use a megabyte or more. I stop counting include() when I get to 13. File operation on a shared server are costly and will really slow down a PHP script. Slow scripts will find themselves in TOP 10 processes too often and once again perk the host's interests.

Memory footprint and file operations are two things that concern me when running anything on a shared server. Of course you can usually get away with running anything, if you have no traffic to load it.

Re:Give me a break.

[Fweeky]

Yup, that's kinda why I said "I wonder why it hasn't taken off", given so many people were really itching for the new features (even if they removed half of them during ZE2 development, meh). Oh, and you didn't explicitly say anything about usability, just "cleaner" ;)

Seems a bit like a chicken and egg problem in some ways; very few people use the new features because most people don't have control over their own servers, so those that do have control don't see a point in upgrading because.. nobody uses the new features. Having a few big-name apps start requiring them and making obvious the benefits would probably go a long way towards helping the demand side.

Not that I don't see it as a good thing to see users find better languages for them; a monoculture where "web scripting" == PHP really isn't healthy, I don't care how free it is. Competition makes everything suck less :)

Re:Give me a break.

[unlinear]

*.php and *_class.php or *.class.php

duh?

Re:Give me a break.

[Gnulix]

*.php and *_class.php or *.class.php

And that's more secure? Having include and class files that are "executable" is more secure than having files namned .inc (that may or may not be downloadable, but shouldn't be "executable")?

duh?

Duh, indeed...

Safe mode

[doctela]

One of the problems with Gallery 1 was that it would not run with PHP's safe mode, which is often used in shared web hosting. Does Gallery 2 also have this restriction? (The site's still slashdotted.) There are other PHP-based photo gallery solutions that do not have this restriction, such as Coppermine http://coppermine-gallery.net/index.php.

Re:Safe mode

[Anonymous Coward]

Yes, this restriction still exists. There is a very lengthy discussion on the Gallery forums you should check out once they are back to full working order.

3years, 9 developers?

[Anonymous Coward]

"Be aware that we have very high standards for core team members and we expect them to contribute at least 5-10 hours a week to working on the project."

Okay so, lets say each developer spent 7.5hours a week, 9 developers. 390h per year, 3 years work 1170hrs per developer.

So they're saying there's ~10,530 hours of work on this project? (plus about 35 "code contributors", and they use a library for the only decent thing on it, the templates)

It doesn't even look like a lot of thought went into coding it because.... well look at the code and you'll find out (saberworks lists a few of the problems). If they said 3 weeks (or months even) perhaps it might be a bit more believable.

Take off your idiot caps

[Anonymous Coward]

and read the summary morons.

Over three years of design and development have gone into creating the best online photo management product possible.

Wordpress support

[Coppit]

To easily include gallery pictures in your blogs, check out the wpg2 plugin.

Re:Wordpress support

[mikrorechner]

Also not to be missed:

The iPhotoToGallery-Plugin.

Makes photoblogging really easy.

What does it do.....

[redwoodtree]

What....does..... it..... do......

online photo management, sorry, i'm not in the field.

Coppermine

[Derf_X]

Coppermine seems nice, but I never tried it since all my pictures (1100+ pictures) are already on Gallery.

JAlbum was the first I tried, but it was not practical for adding pictures to albums and comments to pictures, so I switched to Gallery. It works for me since I have my own server on a DSL line. Mambo is already slow on it (P166MMX), so I suspect Gallery 2 will be the same since it also uses MySQL.

You're right about the professional IDE

[Mustang Matt]

I used the zend studio IDE years ago and it was sharp at the time but I don't think it's cheap to purchase now.

I was hoping to see more from PHPEclipse. Quite honestly, the plugin was a dissapointing to me. I don't see any reason to tie it to the XAMPP packages and it loses so much of the awesome functionality of Eclipse that I quickly resorted back to Macromedia homesite for a glorified text editor.

Second to one

[fulldecent]

Camera Life is so much better: http://fdcl.sf.net

mysql_connect()

[rsd]

whats the point of

the Gallery 2 framework is particularly interesting because it's written with modern programming patterns (OOP, extreme programming, test driven development, MVC, factories, modularity, ...)

If they still have not got the basics:

Warning: mysql_connect(): Too many connections in /usr/www/website/drupal.gallery2.org/includes/data base.mysql.inc on line 31 Too many connections

Every PHP+MySQL HowTo^H^H^H^H^Htutorial explains that mysql_pconnect() should be used.

Re:mysql_connect()

[Anonymous Coward]

That is drupal, not gallery...

Re:mysql_connect()

[CProgrammer98]

A comment from the mysql_pconnect man page (NOT written by me though):

Normally you do NOT want to use mysql_pconnect. This function is designed for environments which have a high overhead to connecting to the database. In a typical MySQL / Apache / PHP environment, Apache will create many child processes which lie in idle waiting for a web request to be assigned to them. Each of these child processes will open and hold its own MySQL connection. So if you have a MySQL server which has a limit of 50 connections, but Apache keeps more than 50 child processes running, each of these child processes can hold a connection to your MySQL server, even while they are idle (idle httpd child processes don't lend their MySQL connection to other httpd children, they hold their own). So even if you only have a few pages which actually connect to MySQL on a busy site, you can run out of connections, with all of them not actually being used.

In general use mysql_connect() for connecting to MySQL unless that connection takes a long time to establish.

Re:mysql_connect()

[elemental23]

Note that their web site is running Drupal, as Gallery is a photo gallery, not a CMS. They didn't write the code their site is running on.

So is their main site indicative of code quality?

[elronxenu]

I clicked on the link http://gallery.menalto.com/gallery_2_0_released . I thought it looked good. Then I scrolled down and looked at the bottom of the page:

Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /usr/www/website/drupal.gallery2.org/index.php:39) in /usr/www/website/drupal.gallery2.org/includes/sess ion.inc on line 10 Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /usr/www/website/drupal.gallery2.org/index.php:39) in /usr/www/website/drupal.gallery2.org/includes/sess ion.inc on line 10 Warning: Cannot modify header information - headers already sent by (output started at /usr/www/website/drupal.gallery2.org/index.php:39) in /usr/www/website/drupal.gallery2.org/includes/boot strap.inc on line 448

Plus half a page of unreadable junk which I won't even try to get past the lameness filter.

I think I'll wait for Gallery 3.x

Easy?

[Anonymous Coward]

I'm glad you think designing, coding, building RT non linear audio-video edit suites is "the easy part".

incredibly pleased?

[psycho]

> We are incredibly pleased to announce the release of Gallery 2.0!

Incredibly, as in we cannot possibly believe how someone can be so pleased about releasing this shitty product? Enough with the meaningless overstatements already -- it makes your language weaker, not stronger.

Here's the content I got from the demo page.

[neo]

.menalto.com/" /

Seems their site's working just fine.

use Gallery 2 to share the moments of life!

[scaturan]

i've been using the Gallery platforms for more than a year and maintain a few hundred g1/g2 sites for friends, family and customers. tired of being bombarded with invasive advertising on commercial portals? get a paid hosting account and use Gallery 2 to share the moments of life with friends & family! you won't regret it, at least i didn't =) props to Bharat and his crew!

Re:So is their main site indicative of code qualit

[Anonymous Coward]

The warnings are from Drupal, which would be the site's CMS. The website itself is not run off Gallery. So the warnings have nothing to do with the quality of the Gallery application.

Gallery Remote Not Wprking

[scarolan]

I just upgraded to Gallery v. 2.0, but now I can't use Gallery Remote to upload photos. I keep getting the following error message:

Server contacted, but Gallery not found at this URL ( http://www.mysite.com/gallery2/main.php )

Any pointers? Has anyone else experienced this? Does Gallery Remote work at all with g2?

Re:Gallery Remote Not Wprking

[uss_valiant]

Does Gallery Remote work at all with g2?

Yes it does of course. Please post your settings in the G2 support forum (once the /.ing is over :/).

New site also uses Drupal

[jmarkantes]

This is also the release of the new website running on drupal as a CMS instead of, um, I think phpnuke or something. Should be a nice clean start from the previously confusing and disorganized setup.
J

Not right now

[Plug]

Don't wait, download Gallery 2 now!

Couldn't you have waited till I got my copy first? :)

not natural

[aggieben]

Gallery 2.0 is the natural successor to Gallery 1...

I disagree. I was going to try one of the Beta or Alpha releases of 2.0 a while back, but as soon as I read that it required MySQL, I turned tail and ran.

One of the beautiful things about Gallyer 1.x is that it didn't require a relational database, which IMHO is massive overkill for such a simple application from a data perspective.

Re:paid press release on /.?

[larry bagina]

they'll make it up on volume

No

[ImaLamer]

The code name for the project would be Minneapolis and the final product would be called Opportunity.

Funny Website

[Wassini]

Maybe im getting to old, but I think that You have to be more than a nerd to read a site that is shown like this: (I'm using Firefox to browse http://gallery.menalto.com/)

@import "misc/drupaTxxhtmla//tyle > .ricp-search-form input.form-submit {marginF noo o0 1em;} .ricp-search-more-link { fnte-weight: bold; fnte-tyle :italic;} .ricp-search-excerpt {fnte-weight: bold;} //tyle >

Mod me down, but...

[gottabeme]

Well, mod me down, but by golly, you're right!

Better (simple) error reporting

[gottabeme]

Ok, I haven't looked through Gallery's code, but I've done some PHP coding myself, and once I discovered this technique, I used it on everything.  It's so simple, and works so well.  Just include it and forget it, and do a user_error() when you need to.

<?
    error_reporting(E_WARNING | E_ERROR | E_PARSE | E_NOTICE);

    function errorHandler ($errorCode, $errorDescription, $scriptFilename, $lineNumber, $context)
    {

        // If it's an E_NOTICE error, don't do anything
        if ($errorCode == 8) return;

        // Gather data
        $date = date('Y/m/d H:i:s');
        $remoteHost = $_SERVER['REMOTE_ADDR'];
        $url = $_SERVER['REQUEST_URI'];

        // Construct error message
        $error = "\n";
        $error .= $date."\n".$remoteHost."\n";
        $error .= $url."\n";
        $error .= $scriptFilename."\nLine ".$lineNumber."\n";
        $error .= $errorCode.': '.$errorDescription."\n";

        // Write error to log
        if (getcwd()) $prevWorkingDir = getcwd();
        chdir(dirname(__FILE__));
        $fp = fopen('script_error_log.txt', 'a');
        fputs($fp, $error, strlen($error));
        fclose($fp);
        if ($prevWorkingDir) chdir($prevWorkingDir);

        // Print an error message, (send an email too if you want, just add mail()), then exit
        echo '<div class="errorMessage">An error has occurred and has been logged.  Please contact <a href="mailto:webmaster@h...com">webmaster@...com</ a> if this problem persists.</div>';

        if (!mail('webmaster@...com', 'Script Error Logged', "An error has occured in the scripts.  Here is the error that was logged:\n\n".$error)) {
            echo "Error e-mail not sent.  Please contact the webmaster.";
        }

        exit;
    }

    set_error_handler('errorHandler');  // Set error handler to my handler

// Put everything above this line into your standard include

    if (!do_something()) user_error("Something didn't work.  This will log the error, mail it, print a friendly message, and stop.");
?>

Quality indeed

[Anonymous Coward]

From my amateurish point of view Gallery2 sets the the bar high for other free web applications.

I have never installed any other free web app as easily as this one. Maintance is easy and logical. And it uses a good templating system (Smarty). E.g. many of the content management systems i've tried use a wicked templating system.

Of course i'm pleased with any app that i need and is available free of charge...

autorotate missing

[richlv]

i usually try to rotate all my pictures with jhead before writing them on cds - but in some of the older cds they were written as-is. now i would like to pump all the images in gallery, bet v2 does not support autorotation based on exif header information.
g1 supported it.
well, i could copy all images on hdd & run jhead on them (crappy solution), or install g1, add pictures, then try migrating - also crappy solution.

if i could write good code, i could try adding this feature (doesn't seem extremly complicated :) ) - but i can't.

so, if there is anybody in /. who knows php and could add autorotate support to exif module of gallery - that would be really nice.

gallery developers are very friendly and will introduce you to necessary details if you are interested & capable.

MOD PARENT WAY DOWN!

[bhiestand]

The asshole redirected pics.jeremylevy.com to quarterlifeliving.com! Google confirms that gallery used to be run at that URL, but that site will not do any good to the /. community now.

Re:MOD PARENT WAY DOWN!

[jelevy01]

Yea.. I decided it was a bad idea to have my pics site on slashdot so I put up a redirect...

Re:MOD PARENT WAY DOWN!

[Placido]

Yeah well you seem to have removed the redirect now so you should probably put it back in place... NOW THAT I've given my heart to the girl in black (Julie and Matt's Wedding 005)! Bastard! Anyway, tell her that her star crossed lover is waiting in England. I can offer 1000 camels for her hand in marriage... or 900 sheep if she's from New Zealand.

Re:Database required? No prob for me...

[msh104]

are there people these days that run a webserver without a database? I surely ran a database together with my webserver from day one... so it doesn't really give much overhead. and database queries do have there merits.

Gallery's Antithesis

[Darius__]

Awhile back I created my own 'gallery' program (before I'd even heard of Gallery). Its premise is that it's only one file, and everything is 100% automatic. All you need is PHP and Imagemagick on the server. Then you set the directories to be indexed writable by the webserver user (for thumbnail creation). Voila! It takes care of the rest. You can check out the sourceforge page at:
http://image-indexer.sourceforge.net/
also, my site using it is http://haven.loki.ws/digcamera

It's not quite as feature rich perhaps as Gallery, but it works very fast and does the job exceedingly well.

I wish it had iphoto integration

[redmoss]

Wouldn't it be cool if you could manage your Gallery using iphoto? You could make a local iphoto album as normal, and then publish it to Gallery. The publisher could take care of uploading and synchronizing everything. If you changed something on the Gallery side, you could then synchronize it back into iphoto.

I can only wish...

Re:I wish it had iphoto integration

[Anonymous Coward]

http://zwily.com/iphoto/

Iphoto-to-gallery plugin.

Re:I wish it had iphoto integration

[uss_valiant]

I wish it had iphoto integration

http://zwily.com/iphoto/

Over-engineered?

[hsoft]

I didn't look at the code, so I just assume just assumer g2 is over-engineered from what you wrote.

I find it funny that g2 is over-engineered because it is specified in the article that XProgramming was used to develope it. And one of the advantage that makes XProgramming so great is that it should prevent you from over-engineering your stuff.

Security

[Anonymous Coward]

Ooh ooh, can you still download the album.dat file and get details about all the images in a "locked" gallery?

Re:So is their main site indicative of code qualit

[elemental23]

Note that their web site is running Drupal, as Gallery is a photo gallery, not a CMS. They didn't write the code their site is running on.

Re:So is their main site indicative of code qualit

[unlinear]

not only that, but that's the way any PHP script would handle session/cookie setting after an error. If content's already been output to the browser (error messages, duh) there's no place to send headers.

the only way you can handle this is by catching exceptions. and yes, that'd be drupal's concern, not Gallery's.

WTF?

[fm6]

When you start a web site about a new project , please include a blurb somewhere that says WTF the thing is. And if you forget (as you usually do), please add it when you issue a breathless announcement, so people reading the announcement know WTF you're talking about. And if you forget (as you usually do), hope that the Slashdot editors will think to add it, so the poor readers will know WTF the project is that it's rates front page status. And if you forget (as you always do), well, WTF...