New Module: favourites

Here's a new module that adds a dynamic album of user-selected favourites.

Installation adds a new map to the database, and an ItemLinks item, "add to favourites" (which changes to "remove from favourites" when that item is already marked as a favourite. Please note there may be some cacheing issues at the browser with regard to this change of menu item.)

As it stands, the add to favourites option is available for guest users too, and directs them to a message suggesting they register. It could be modified simply to remove the option for guests, but that wasn't what I wanted.[edit - this is now configurable on the admin page]

As soon as a user has registered one favourite album or photo, a new SytemLink appears, "Favourites" which displays the dynamic album of Favourites.

All comments and bug reports gratefully received.

[edit]
now available from the community repository - see your admin/plugins/get more plugins page.

1. Will do

2. Is there any documentation on this? I appreciate the policy distinction between views and controllers - what's the practical difference? Also, is there an api for the green/red java boxes used for activating new modules? That would be a more appropriate way to handle this

3. If anyone has a mind to take this on that would be great. After three weeks of struggle, I still don't understand the Gallery api well enough for this.

4. Inasmuch as I understand you, I don't agree. Users can only see items they have 'core.ShowItem' on, but that's checked in UpdatesAlbumView's loadTemplate function. As for the userId passed to GetChildIds() - that's up to the loadTemplateFunction which calls $this->getChildIds($theme['actingUserId']) - I don't see how that can be subverted. I'm just using the same approach as the getChildIds from the other classes in DynamicAlbums - won't that do?

5. Fair enough

6. I can't possibly spell Favourite without the 'u' - it's just *wrong*

7. It does already

8. Fair enough

2. ok, I'll have another crack at this.

4. I'm sure you're right (ok, I'm being polite) but I followed exactly the model from the existing DynamicAlbums module and I really can't see a security hole: are you saying that users can have items displayed that they don't have core.ShowItem for? Or that users will be able to load others' favourites? Either way I can't see how, so please elaborate!

(if you're going to do number 3 that's great, but give me a few days to look at 2 and 4 first, but I'd appreciate more info on 4 so I can see the issue too.)

On spellings: I've put up with catalog instead of catalogue, color instead of colour, and disk instead of disc, for the 27 years since I first laid hands on an Apple ][ ... just think of it as a tiny token of revenge!

No they won't - because 'core.ShowItem' is checked on every item after entries have been fetched from the map but before anything is shown to the user. Of course that means they won't be able to remove the item from their favourites - but that's not a problem. It should stay as a favourite so that if they regain their permissions, it will once again appear as a favourite for them.

k, my bad, misreading the loadTemplate code in a hurry. I'll add a check for core.view permission on each item, probably in the helper class when the collection is loaded from the map.

Aargh no, sorry, I'll get back into it this week. Thanks for letting me know that someone else will use it too!

Ok... this module is now updated.

Changes:

• I have implemented Valiant's suggestions about the database table (correctly, I hope)
• The loading of thumbnails is protected by a check for core.view on each
• A controller is used to add/remove favourites, not a view (and it's the same controller for both functions)
• Site admins can view other users' favourites (by setting g2_targetUserId=xxx in the url)
• there is a url_rewrite option (3 in fact) for /favourites, /favourites/%targetUserId%, and also /favourites/%targetUserId%/%page% - take your pick or use all three.

Still to do:

• Add code to delete a user's favourites when a user is deleted
• Add an admin page, which will show which users have how many items registered as favourites, and make it easy to see them (so you don't have to enter the targetUserId into the url)
• The url_rewrite with target and page doesn't replace outgoing urls - although they work correctly if manually entered in the browser. (I'm not sure why.)
• When you've added or removed a favourite, the back link takes you to the image - this might not be correct if you used an ItemLink under a thumbnail in themes that support such a thing. I need to think about how better to implement this.

I think it will be straightforward to turn this into a Lightbox module for those who want one (please add a post on this thread if that's you) but it will be a fork of the code, my original use doesn't need that kind of complexity!

Please go carefully before installing this on a production server at this time, I'm sure there are some bugs. But if you want to try it and let me know what you can find that needs fixing, that would be great!

Also code reviews appreciated :whistle:

note: please update your first post of this topic. the latest version should always be the first download listed. else users end up with obsolete versions.

@root album:
$root->getId() returns the root album's id (usually 7, but it's not hardcoded).
$root->getParentId() returns null.

--------------
Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage

that only happens to replies, but not to the topic / "article." or in drupal-speak: you'll edit a node, not a comment.

I think this module is great! Yet another "dynamic" album, cool.
Just a minor suggestion; define variables to prevent Notice errors:

&

Keep up the great work.

Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team

Version 0.2.1 for you all...

Chris that should be fixed now. And Dave, the undefined variables should be defined.

New in this version:

• An admin page, from which you can check people's favourites.
• configurable whether to tease guest users with the add to favourites command or not
• Ability to set theme preferences for favourites pages (please give this a test for me) again from the admin page

Still to do:

• Page through the users on the admin page in case there are hundreds
• Still having problems with caching on the root album
• url_rewrite seems inconsistent (doesn't work on the admin page for example, at least not on my system)

Please test and feed bugs back here.

Enjoy!

Chris,

I don't that that's possible within the gallery structure - the Add/Remove item is just a regular ItemLink and will show up under every item for which it's valid, be that under the thumbnail for the item, or the larger image, according to where the theme normally displays ItemLinks. The code which decides whether it should be "Add...", "Remove..." (or neither) isn't provided with the context within which the ItemLinks are being sought.

If anyone knows different, let me know, but that's how I understand it to be - sorry.

(For myself I prefer themes without the itemLinks under thumbnails, I think they're terribly messy.)

That's an easy hack then - Just add the slideshow link manually in your album.tpl template, under the code where each thumbnail is displayed, and leave the automatic ItemLinks turned off there.

Curious... and tricky, since you don't get a full error log as a guest.

Can you change this line in your config.php:

$gallery->setDebug('');

to:

$gallery->setDebug('buffered');

and send me (pm if you prefer) the debug output?

Personally I *want* the link shown to guests (so when they use it they can be encouraged to join up) - but it's configurable in the admin page - that's the "Offer Favourites to Guests" that Chris mentioned.

Is it true that !registered_user => anonymous_user ?

Oh, I'm also working on localising (localizing?) the module so Favourites appears as "Favorites" (ick) for the benefit of our cousins.

@localization:

Cough Cough... maybe an international product like Gallery2 should be such that it doesn't assume this?

When I can get make to produce a po file (it's consistently failing at the moment), I've no problem translating the strings back to US English (since I can then have them localized), but I'd rather have the URLs spelt correctly for my British customers (i.e. have the module name as favourites). And nobody else has bothered to write this module any time in the last four years.... ;-)

By the way, I've been following the info in that link, but as I say, I can't get the po file out:

cassiopeia:/home/alec/gallery2/modules/favourites/po# make en_GB.po
extract.php parse error: templates/FavouritesNotify.tpl:
>
make: *** [messages.po] Error 1
cassiopeia:/home/alec/gallery2/modules/favourites/po#

Any suggestions?

I do understand, I think - you said it's not possible to write a module whose original text is in anything other than US English, because Gallery will not touch an en_US.po for users whose preferred language setting is en_US. That's a great pity, and a disservice to module authors (and potential authors) whose first language is not American English.

If you could find the time to have a quick look at the failing .tpl that would be fab!

The fact that the Internet is based around US English is a self-fulfilling defect that very many organisations are working hard to remedy. I'd prefer to think that Gallery supports translations not because it's easy, but because it's the "right thing to do" (trademark specifically *not* acknowleged).

And it's not very likely to be, because your constituency is preselected to be happy with en_US as a default. To be honest, it's a bit of a cop-out to answer every difficult question with "see if it gets enough votes" - there's much that happens in Gallery development that *doesn't* get voted for, according to the priorities of the core developers; I'm not saying this should be one of them, but to answer every suggestion with "see if it's popular" isn't particularly constructive.

I know, we both preferred to discuss the language stuff in a separate thread and if this website made it easy to split off discussions, I'd do it right away...but it's not possible without hacking the DB.
Hopefully my last statement on that sub-topic in this thread:
Although English isn't my first (or even second) language, I'm a proponent of keeping most of the internet in English. In a lot of places, English is either the first or second foreign language. Instead of a tower of babel, everyone understands everything. Communication happens around the globe. Information is freely available to everyone without major barriers.
Machine translation is just not good enough. If I want to read some Chinese websites, I only get a hunch of what they
re actually talking about. And I couldn't participate in any Chinese discussion.

@voting / popular / democracy:
Of course you're right. Not everything should be done even if it's popular and even if some things are not popular, they need to be done.
That's how it works.
We use sfvote mostly for features / requests that are not necessarily on our roadmap. And for the intersection of our roadmap / of things we deem important for the success of the project / software and popular requests, we use sfvote as an indication of what we should prioritize.

Do we only offer Gallery in US English or is it the only default? No, the default language is configurable and G2 even adjusts to all visitors' preferred language.

The level of flexibility you request is deeper, at the development level. It would be nice to have, but if you look at all the other things we need to work on, I can't prioritize this very high. This is where patches / sfvote / community development comes into play. If this is something someone needs and if the patch is reasonable, you're not depending on one of the few core developers to implement the feature. It can find it's way into G2's core module by 3rd party development with code reviews from the core team.

Anyhow, back to the favourites module.

--------------
Documentation: Support / Troubleshooting | Installation, Upgrade, Configuration and Usage

New version posted - 0.2.3. It has an improved admin page.

Yes, that's a typo. I still need to get the url rewrite functioning the way I want it to, though, so I think that block of code may get rewritten.

Glad you like the plugin otherwise!

alec,
thanks for making this available! It seems to work great, except for some of the URL rewrites as you mentioned. Also, how does this affect duplicate content penalty? Now we have two copies of the same image/content (original) and (favorites).

Thoughts?

Hi all!
Thanks a lot for this nice module. It's exactly what we needed.

..but..

I know that's problem on my site, but don't really know what I have to do for fix it. I installed this module, "Add.." and "Remove.." options are working properly, but if I want to go to "Favourites" dynamic album, it shows just blank page and browser says "Done" - so I think there's no bad script.

I checked it in Opera and IE as well.

Source code in blank page is just:

Thank you for any answer!

I think this is what you need:

I've got 0.2.3 of course. I already tried to reinstall it, but it didn't help. I'm going to try it again, but....

EDIT: The reinstall didn't help.

There's a typo in one of the files that means the dynamicalbum module needs to be installed for this module to run- thanks for drawing my attention to this. I'll try to upload a fixed version later on. You should then be able to remove the dynamicalbum module.

I'm not entirely sure what areas of the page your two questions are asking about, as they depend on the theme that you're using. To change the Favourites link from being a Systemlink to (I guess) an ItemLink you'd need to rewrite the part of the module.inc file which define those links for this module.

Nice Idea!

I've updated the module to 2.2.4, deleting the line which (mistakenly) inserts a dependence on the dynamicalbum plugin, so you should no longer require that module to use this one.