Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Programming IT Technology

Gallery 2.0 Released 224

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."
This discussion has been archived. No new comments can be posted.

Gallery 2.0 Released

Comments Filter:
  • FYI (Score:4, Informative)

    by Anonymous Coward on Tuesday September 13, 2005 @06:22PM (#13551658)
    http://en.wikipedia.org/wiki/Gallery_Project [wikipedia.org]

    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.
  • +5 Insightful! (Score:5, Insightful)

    by h0bbel ( 105687 ) on Tuesday September 13, 2005 @06:22PM (#13551666) Homepage
    RC1 was codenamed +5 Insightful, how nice :)
  • Gallery (Score:3, Insightful)

    by Saiyaman ( 859809 ) on Tuesday September 13, 2005 @06:25PM (#13551701)
    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 (Score:5, Informative)

      by Scooter ( 8281 ) <owen AT annicnova DOT force9 DOT net> on Tuesday September 13, 2005 @06:53PM (#13551926)
      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.
  • by staticdragon ( 95211 ) on Tuesday September 13, 2005 @06:26PM (#13551709) Homepage
    Anyone have an alternate link or a server thats running it since the site is borked?
  • by banglogic ( 702448 ) * <Ken.Knicker@ n u v een.com> on Tuesday September 13, 2005 @06:26PM (#13551717) Homepage
    I have been using JAlbum [jalbum.net] 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?
    • by Titanium Angel ( 557780 ) on Tuesday September 13, 2005 @06:33PM (#13551779)
      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 :)
    • by Arathrael ( 742381 ) on Tuesday September 13, 2005 @06:46PM (#13551872)
      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. :-)
      • by Titanium Angel ( 557780 ) on Tuesday September 13, 2005 @06:58PM (#13551973)
        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.
      • by HeelToe ( 615905 ) on Tuesday September 13, 2005 @07:30PM (#13552257) Homepage
        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.
    • by Anonymous Coward on Tuesday September 13, 2005 @08:47PM (#13552919)
      I have been using Quick Digital Image Gallery [sourceforge.net] 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.
    • Coppermine (Score:2, Informative)

      by Derf_X ( 651876 ) on Tuesday September 13, 2005 @09:19PM (#13553136)
      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.

  • PHP != Crap Code (Score:5, Interesting)

    by ilkahn ( 6642 ) on Tuesday September 13, 2005 @06:27PM (#13551726) Homepage
    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.
    • by man_of_mr_e ( 217855 ) on Tuesday September 13, 2005 @06:37PM (#13551807)
      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.
      • by B3ryllium ( 571199 ) on Tuesday September 13, 2005 @06:49PM (#13551891) Homepage
        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 (Score:4, Interesting)

        by ilkahn ( 6642 ) on Tuesday September 13, 2005 @06:51PM (#13551916) Homepage
        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 (Score:5, Interesting)

          by NickV ( 30252 ) on Tuesday September 13, 2005 @07:26PM (#13552236)
          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 [apache.org] . 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 [jcp.org] or Tapestry [apache.org] (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 [hibernate.org] 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.
          • by ngunton ( 460215 ) on Tuesday September 13, 2005 @08:20PM (#13552704) Homepage
            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.
          • by ilkahn ( 6642 ) on Tuesday September 13, 2005 @08:23PM (#13552720) Homepage
            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.)
            • by NickV ( 30252 ) on Tuesday September 13, 2005 @08:55PM (#13553000)
              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.
              • by ilkahn ( 6642 ) on Tuesday September 13, 2005 @09:13PM (#13553102) Homepage
                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 :)
          • by killjoe ( 766577 ) on Tuesday September 13, 2005 @08:39PM (#13552847)
            "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.
          • by Mustang Matt ( 133426 ) on Tuesday September 13, 2005 @09:21PM (#13553143)
            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.
        • by man_of_mr_e ( 217855 ) on Tuesday September 13, 2005 @08:35PM (#13552828)
          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).
    • by stor ( 146442 ) on Tuesday September 13, 2005 @11:45PM (#13553954)
      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
    • by Nurgled ( 63197 ) on Wednesday September 14, 2005 @03:00AM (#13554849)

      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.

    • by Trak ( 670 ) on Wednesday September 14, 2005 @09:03AM (#13556259) Homepage Journal
      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.
  • Marketing (Score:3, Funny)

    by gunpowda ( 825571 ) on Tuesday September 13, 2005 @06:28PM (#13551735)
    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'.

  • by tonigonenstein ( 912347 ) on Tuesday September 13, 2005 @06:30PM (#13551747)
    OOP, extreme programming, test driven development, MVC, factories, modularity
  • Slashdotted (Score:3, Informative)

    by xot ( 663131 ) <fragiledeath AT gmail DOT com> on Tuesday September 13, 2005 @06:33PM (#13551777) Journal
  • by swillden ( 191260 ) * <shawn-ds@willden.org> on Tuesday September 13, 2005 @06:40PM (#13551831) Journal

    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.

  • by TimCrider ( 215456 ) on Tuesday September 13, 2005 @06:46PM (#13551875)
    Slashdot Effect [ FAILED ]
  • Anyone have a cache or alternate download page?
  • by Karamchand ( 607798 ) on Tuesday September 13, 2005 @06:56PM (#13551957)
    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 [sourceforge.net]
  • by bkessels ( 796275 ) on Tuesday September 13, 2005 @06:58PM (#13551979) Homepage
    For those interested. Gallery is the next big one in line to move its site to drupal [drupal.org]
  • by jackstack ( 618328 ) on Tuesday September 13, 2005 @07:07PM (#13552071) Journal
    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.
  • by anglete ( 782289 ) on Tuesday September 13, 2005 @07:09PM (#13552096)
    Try out Gallery Local [sourceforge.net], 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.
  • My Gallery (Score:2, Interesting)

    by jelevy01 ( 574941 ) on Tuesday September 13, 2005 @07:17PM (#13552161)
    If anyone cares here is my gallery: http://pics.jeremylevy.com/ [jeremylevy.com]
  • Give me a break. (Score:4, Interesting)

    by saberworks ( 267163 ) on Tuesday September 13, 2005 @07:48PM (#13552402)
    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. (Score:5, Informative)

      by Warren_Canuck ( 522319 ) <warren@halifr a g . com> on Tuesday September 13, 2005 @09:08PM (#13553072)
      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. (Score:3, Interesting)

        by Fweeky ( 41046 ) on Tuesday September 13, 2005 @11:45PM (#13553953) Homepage
        "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. (Score:2, Interesting)

          by Warren_Canuck ( 522319 ) <warren@halifr a g . com> on Tuesday September 13, 2005 @11:58PM (#13554016)
          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.
          • by Fweeky ( 41046 ) on Wednesday September 14, 2005 @12:27PM (#13558112) Homepage
            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 :)
    • by hsoft ( 742011 ) on Wednesday September 14, 2005 @09:41AM (#13556562) Homepage
      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.
  • Safe mode (Score:2, Informative)

    by doctela ( 889621 ) on Tuesday September 13, 2005 @08:03PM (#13552550)
    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 [coppermine-gallery.net].
  • Wordpress support (Score:3, Informative)

    by Coppit ( 2441 ) on Tuesday September 13, 2005 @08:50PM (#13552943) Homepage
    To easily include gallery pictures in your blogs, check out the wpg2 [ozgreg.com] plugin.
  • Second to one (Score:3, Informative)

    by fulldecent ( 598482 ) on Tuesday September 13, 2005 @09:37PM (#13553251) Homepage
    Camera Life is so much better: http://fdcl.sf.net [sf.net]
  • mysql_connect() (Score:3, Informative)

    by rsd ( 194962 ) on Tuesday September 13, 2005 @09:42PM (#13553277) Homepage
    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() (Score:3, Informative)

      by CProgrammer98 ( 240351 ) on Wednesday September 14, 2005 @07:10AM (#13555675) Homepage
      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.
    • by elemental23 ( 322479 ) on Wednesday September 14, 2005 @01:27PM (#13558710) Homepage Journal
      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.
  • I clicked on the link [menalto.com]http://gallery.menalto.com/gallery_2_0_released [menalto.com] . 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

  • by neo ( 4625 ) on Tuesday September 13, 2005 @10:28PM (#13553507)
    .menalto.com/" /

    Seems their site's working just fine.
  • by scarolan ( 644274 ) on Tuesday September 13, 2005 @11:57PM (#13554009) Homepage
    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 [mysite.com] )

    Any pointers? Has anyone else experienced this? Does Gallery Remote work at all with g2?
  • by Plug ( 14127 ) on Wednesday September 14, 2005 @12:10AM (#13554074) Homepage
    Don't wait, download Gallery 2 now!

    Couldn't you have waited till I got my copy first? :)
  • by aggieben ( 620937 ) <<aggieben> <at> <gmail.com>> on Wednesday September 14, 2005 @01:14AM (#13554383) Homepage Journal
    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.

God may be subtle, but he isn't plain mean. -- Albert Einstein

Working...