Home developers blog

Moa

An easy to use open source web
image gallery for PHP/MySQL
Developers blog
Some Moa 1.3 template thoughts Wednesday, 21 March 2012 20:22
Written by Dan Brown   

It's been slow going recently as both rich and myself have been doing various other things but work still continues on Moa 1.2.7. We have decided to reshuffle the list of what needs doing a bit to combine the planned features from 1.2.7 and 1.2.8 to make this the final release in the 1.2.x series. "Pretty" URL are done, preview caching was added as a new idea and still being finished up now and we've generally tidied some loose ends up a bit.

While  that is going on we also started a new template. For 1.3.x we want to split out all but the default template and have them as separate downloads, but with only three templates currently I thought a new one would be worth adding. As I've mentioned before I am not a designer so I looked around the world of free WordPress design .PSD files (design-only, not the actual templates) for some ideas. I've found a few elements that seem to work well together and I've got most of the new one done.

However in looking at designs I've noticed something that may impact how we should support templates. Almost without fail, gallery or thumbnail templates are designed for fixed aspect-ratio images. Supporting both portrait and landscape formats, and with variable extremes of rectangle, just doesn't make an appearance. But as we want to support any images for ease of use it complicates things as it will break some designs. The options we have to help guard against it are -

  1. Make the thumbnail frame fixed regardless of the image size. We already do this with the MoaDefault templates and it is OK for small thumbnails. But looks odd with large thumbnails, such as this new templates 300+ pixel wide ones with just 3 per row.
  2. Have separate templates for fixed vs. flexible layouts. The easiest for us, but as soon as someone uploads an image of the wrong shape it looks bad.
  3. Automatically crop thumbnails to fit. Will look right but we don't know where the crop should be so will usually be the wrong option.
  4. Allow users to mark a crop area themselves as part of the image edit. Best for people who know about it, but goes against our key goal with Moa, an audience of non-techies. Plus would be a PITA for larger bulk-uploads.
  5. Expect people to edit the images before uploading. The worst option.

Currently we aren't sure which is the best option (definitely not option 5 though). Most likely it will be option 2 with the ability to do option 4 as well.

 

Having 'advanced' features like that also bring up something new we have planned for 1.3.x - Plugins. This will allow us to keep the basic Moa simple as is our goal, but support the techy extras that some users may want. The current slideshow and site map would be converted to plugins for example to keep the base install simple. Other ones would be a filmstrip,search, XML sitemap, movie clips, EXIF data and geotagging. If we can work out a way to get plugins into the very core, the tag-based galleries could also be moved to it's own plugin. This would be harder though as it is quite deeply embedded currently so would need a more powerful plugin system than the others.

Others possible, but not planned by us would be comments, ratings, social media integration. We didn't want to add these as they complicate things for the base install but this way everybody wins.

 
Refactor 2.0 and the future! Tuesday, 30 August 2011 22:25
Written by Dan Brown   

Version 1.2.6 is now pretty much ready, just got to do some final testing and get the upgrade/install up to date.

 

Refactor

 

One of the biggest things this release is behind the scenes in the form of a refactor.  We did this before way back in May 2009 but code drifts and it was starting to get painful to change things and add new features again. About four months ago I decided to try and rejig one of the JavaScript files as it was getting a bit unwieldy. So I checked out the code into a separate directory and I ended up changing so much (pulling all callbacks into a single method, moving to jQuery, switching to JSON as the AJAX comms system, etc) that I just had to go ahead and change all the other JavaScript files to match.

This is what delayed 1.2.5 a while and just when that was done and we were going to merge it into the main branch to release... I decided that the main PHP classes had to be done as well. So we just pushed out the new features by themselves and left the refactored branch to wait for 1.2.6.

The main classes were a bit of a mess to be honest. We had a class for example called Gallery which dealt sometimes with one gallery and sometimes with several, and a bunch of gallery related functions outside the class. Now Gallery deals with just one gallery at a time and is persistent for the page generation so fewer database hits. The functions for dealing with multiple galleries are moved to static methods in the Gallery class to use it's namespace. The same goes for the Image, User and Tag classes. It is so much nicer to work with now and easier to add new stuff.

 

Just wanted to say why the previous release and this one have had a delay that their features don't reflect. Although we have 2 good new features in 1.2.6, you'll have to wait until the release announcement to see what :)

 

Future plans

Now thinking ahead to 1.2.7... Just one weekend before I decided to hit the JavaScript code four months ago I spun off another branch of the code to start what is to be the main new thing in 1.2.7 - URL rewriting. It mostly works in that branch so should be quick to put into place. It means that instead of the current ugly URLs such as http://www.somedomain.com/gallery/index.php?action=image_view&image_id=33&parent_id=54 we can use http://www.somedomain.com/gallery/my_holiday/Brazil/some_cliffs. Much nicer to work with and may help some towards Google Images starting to index your pics as viewing the full image also includes the original filename (which can be customized). The old URLs still work so it won't break bookmarks or links. We have a few other minor bits penciled in for 1.2.7 but I wouldn't be surprised if we can fit in another nicety as well.

 

1.3.x we also have been having some plans for. We had decided a long time ago that we need a better way to administer images and galleries without jamming more and more JavaScript into the main pages like we have now. 1.3 has been earmarked for this part for a long time. Exactly how we weren't sure of but it would be based around a gallery and image manager on the admin pages to see everything in one place. This should allow things like re-ordering, choosing the pic to use for gallery thumbnails and seeing errors all in one place. A few weeks ago we came up with a solution that will complement this focus on better admin which is to split Moa into a front and back end much like Wordpress and CMSes do. Being able to separate the admin code entirely makes adding user features simpler as we don't have to worry about breaking admin code while we do it. The templates especially can be so much simpler as they don't have to reserve space for admin features or feedback at all. We can also add some CMS-style abilities like turning on and off the features you want without you having to mess with the templates themselves.

The stated goal of Moa is be a gallery that is simple enough for anyone to use and not just pile on the features. We do have to balance that with ease of maintainability and although we have been heading down the all-in-one-page editting route a-la Google docs/mail I think that this separation is a reasonable tradeoff for the usability and faster turnaround we should be able to get from it.

There is one major strike against Moa in that ease-of-use department which we also have a solution for in mind. It's not something we can talk about yet though and will be a lot of work to implement. We do try to keep Moas goal in mind though with every release.

 

Any thoughts? Leave a comment.

 
A few things. Tuesday, 08 March 2011 21:51
Written by Dan Brown   

1.2.4

Well 1.2.4 is out and doing well so far according to Sourceforge/Freshmeat stats.

 I've noticed one minor issue which I will correct tomorrow and put out as 1.2.4a along with updating the demo. The pagination is showing up on galleries that only have sub-galleries if enough images match that galleries tags. It should be a single file to update so will provide a link to that directly as well to save downloading the whole package. Either way it will just be a case of overwriting the old file(s).

A workaround for now would be to edit that gallery and put a tag that isn't used by any images on it and put it in 'tagged' mode.

 

Cookies

I read an article on BBC news today about a new European law coming in on May 25th that says explicit consent must be gathered from web users who are being tracked via cookies. The law is still being discussed by the web community (at Boagworld for example), especially as it seems rather vague.

Moa uses a single cookie just for the admin logging in and currently won't allow edits without it but it looks like we may be covered just by adding a message to explain this on the admin login page and the documentation. We will put that into the templates for Moa 1.2.5 and see if anyone has made more sense of it by then. For visitors looking at your gallery, no cookies are used by Moa.

If someone wanted to make or modify a template that might embed adverts then of course they can do that, but they would be liable to inform users about any additional cookies that the ads may use.

How this will effect blogs that have adverts I don't know as the page can't always tell if an ad uses cookies or not. It seems incredibly restrictive to force a career blogger to have to mention it on every single page or even provide ad-free versions which may cut their income enough that they can't easily continue blogging. There isn't room in the advert to opt-in on a per-ad basis and that would cut revenue to the bloggers even more as presumably people will rarely opt in.

 

New template

We have a blue variation of the MoaDefault template which we should start distributing but I don't want to stick it in the main package as hopefully we will have several before long and would prefer them to be separate. I'll look into adding a download page to the site to get it out there. We also have a minimal skeleton template we use for adding new features that people might like to look into if they want to make their own template. that needs cleaning up though and some documentation adding.

One of the things we have planned for the next few releases is a template chooser with a screenshot and meta-info in the hope people might look into making templates as we pick up more users. It will also allow notes for the template as some may work better with different thumbnail sizes, etc. Additionally we will be adding a site name to the options to allow it to show on the template instead of the 'Moa' or 'Aperture' logos currently visible.

If anyone wants to give template making it a try we can help out, even if it is just a photoshop mockup we can build it from.

 

CMS move

This site is currently using Joomla as a CMS but I have to admit, I don't like it much... It works but that's pretty much as far as it goes. It is far too complicated for what we use it for.

I'm going to investigate if moving to Wordpress would be better as the back-end is a lot nicer to work with. I can get the data transferred over easily enough, just would have to convert (and finish!) the custom template we use.

 
1.2.4 status Friday, 04 March 2011 23:33
Written by Dan Brown   

I was hoping to get 1.2.4 released last weekend and get into the frequent updates again. Thought it was all done and ready to test but spotted a few things to fix/finish so had to hold back, bah!

 

The main  change is that tags are now optional in your gallery/image organization. New galleries will use 'indexed' mode where images will stick to that gallery no matter what tags are set on either part like any other web gallery. A checkbox on the gallery add/edit form lets you use 'tagged' mode instead which works like classic Moa. We still believe that the tag system or organizing galleries is the more powerful so didn't want to get rid of it completely. I wanted to call the tagged galleries 'live' galleries but Rich pointed out it might mislead people that they were coming from somewhere other than Moa, like from other galleries or Google Image-style.

 

Adding this way of doing galleries opened up the ability to easily add pagination so we did that too. Internally even tagged galleries now actually use an index, it just gets updated more often than an indexed gallery. Therefore we can just add a LIMIT clause into the query and get any subset of the current gallery. Using indices for all galleries also speeds things up a lot for large galleries as the full tagging query doesn't get run every pageview, only when updating tags.

 

Indices also open us up to re-arranging images which we should have soon and is needed, but not going to be in 1.2.4. We still need to plan the best way to get it in place which would be usable. Drag and drop would work, but pagination then causes issues. We have an image manager planned for 1.3 which would allow it but we are several releases away from that still. It's something for us to think about though as I do believe it is needed.

 

Anyway. I've just fixed one of the two remaining problems blocking the 1.2.4 release. Hopefully will get the other sorted in the morning and should be able to test and get it out this weekend.

 
Tag changes Tuesday, 03 August 2010 19:45
Written by Dan Brown   

We've been wondering for a while if the tag/gallery link is unclear to people - It certainly seems so from the people we have watched trying to use Moa. I think it the best thing about Moa personally, but as that is subjective we plan to make a change to help clear up things.

 

So, for the next release the plan is to have a tickbox on each gallery that toggles between "fixed" and "live" gallery views. "Live" is the current system, tags decide what gallery an image ends up in to make the whole system dynamic. "Fixed" will be the default however, meaning that an image uploaded gets linked to that gallery (like a regular web gallery) and the tag field is then entirely optional. Both live and fixed galleries can be used anywhere and an image uploaded to a fixed gallery will be available for a live gallery to use, assuming it has tags. This will hopefully help people get up to speed with Moa as quickly as possible when they first start, but still allow them to play with the live views later if they want.

 

The change involved also makes some of our wishlist much easier, including re-ordering images, multi-page galleries, etc.

 

In other news, this next release (1.2.3) is looking to be a bit of a usability-polish. Currently we are hard at work improving the forms with tooltip help, field checking throughout and some HTML markup improvements. The other two features we want to get in place this time are URL rewriting (SEO-friendly URLs such as www.somesite.com/gallery/Regents_Park/612/trees.jpg) and searching, but those two depend on time.

 

Do you like it? Let us know in the comments below!

 

 
«StartPrev1234NextEnd»

Page 1 of 4
Powered by Joomla!. Valid XHTML and CSS.