RSS module for G2 in the works?

Hi,

I searched the forums concerning using RSS in G2. I've see posts saying it should be pretty easy to create a module for RSS. I've also read that RSS can be used in 1.4.4-pl2.

Is there such a module for G2? If not, is somebody working on it?

Thanks.

Carl

Thanks for the quick response. I could consider trying to write the module. It shouldn't be that hard, right? :wink:

Actually, I'm not even sure anymore it would have to be a "module".

It could be an independant PHP file that queries the database directly to get the description and URL of the last additions. This simple PHP script could have an optional argument to restrict the query to an album.

With my very limited understanding of G2 (I just installed it for the first time yesterday), I don't know what would be the benefits or the disadvantes of creating a module instead of a single PHP page.

Here's some places to look to get started..

• modules/photoaccess/module.inc is a basic module definition.. create a new directory in modules and copy this file for your module.inc. Edit the obvious places; you can remove performFactoryRegistrations().
• look at modules/core/classes/GalleryModule.class for info on module methods
• look at modules/core/classes/GalleryCoreApi.class for the list of common api calls
• for rss you'll probably want an immediate view to return the output.. look at modules/zipcart/Download.inc for an example of an immediate view.

after you define your view you can access it like this:
yourserver.com/gallery2/main.php?g2_view=modulename:ViewName[/]

if you want a parameter to your view our standard one is g2_itemId, ie
g2_view=modulename:ViewName&g2_itemId=number
GalleryView has a convenience method to load that item:
list ($ret, $item) = $this->_getItem();
This loads the item id specified, or the root album of the gallery if itemId is not specified.
you can use GalleryUtilities::getRequestVariables to get any other query parameters you may need.
I think there's a GalleryCoreApi to get all children of an album, in case you need that. You can do $item->getCanContainChildren() on any item to check if you can retrieve it's children.

Answering to my own post... I know... :wink:

I found it.

$urlGenerator = $gallery->getUrlGenerator();
$url = $urlGenerator->generateUrl(array('view' => 'core:ShowItem', 'itemId' => $itemId));

I should be able to get it to work now.

beckett asked me to give a link to the RSS module code:
http://www.carlrobitaille.org/downloads/rss-module-0.1.tar.gz

Take a look at modules/register/classes/GalleryPendingUserHelper::_sendEmail for an example of using GalleryTemplate directly.

geddeth, there is a task for rss support, you can find a link to a forum topic there, and some other notes. There seemed to be some activity some months ago, but it dried out (see forum post), maybe you can revive it? ;)

Cheers,
Ernesto

I have also looked at this, and am interesting and willing to help get rss support into G2.

geddeth, you could use gallery-devel mailing list or the forums to interact, no need to add yet another forum. Most fun happens on irc (#gallery on Freenode). If you come up with something following our coding guidelines, cover all your code with unit-tests, post it to the forums so we can review it and include that to G2's main CVS tree.

Someone pointed out to me that the <lastBuildDate> and <pubDate> tags didn't have a good format. I fixed that (modified RSS.tpl and RSSItem.tpl) and made a new tar.gz.

rss-module-0.2.1.tar.gz

I didn't see the error before because I'm using a PHP script I wrote using MagpieRSS to read my RSS feeds, and I'm not using these tags.

First things first: La Maudite has allowed me to continue work on his excellent RSS module. However, having no experience with the G2 API, I have spent quite a lot of time reviewing the G2 Development StarterKit, the Developer's Guide, the G2 API docs, other modules and of course La Maudite's RSS module itself in order to gain insight into this whole business. I found the hardest bit was to get acquainted with the Smarty API and G2's interaction with it, which is just another way of saying that the G2 API is well thought-through and relatively easy to comprehend.

That being said, I have far from understood all that is going on in this RSS module. So excuse me (Bharat especially) if I've been rather slow in getting this (otherwise simple) module out into the open again, after I promised to do so. I believe the steep learningcurve (and the holidays :lol were my major time-consumers in the past weeks.

So - on to business: the current status of the module can be found here, aptly version-bumped to 0.2.2. It is usable with current CVS, but retains the functionality that La Maudite described earlier in this thread. In module.inc, I have changed the way the (auto-)configuration of the module happens, since I believe 0.2.1 used an old method for this (pun intended ;-)). A diff between module.inc in 0.2.1 and 0.2.2 should reveal these changes.

Regarding your code review, Bharat, these are my comments (or questions, rather):

I have not looked into this. I'd like to, but I feel that you are also interested in getting the module into CVS soon, in which case it would probably be faster if someone on the team could help out. In any case, I'll look into how this is done (and do it, I hope) within a week.

I've changed it to $template->fetch(dirname(__FILE__) . 'modules/rss/templates/RSS.tpl'); - I assume that is what is meant.

I really think La Maudite is in a much better position to answer this than I. If no arguments against changing it appear, I'll do so.

Don't know what this means, sorry. I haven't quite grasped how localization works yet.

Don't know how this works, but have added the g->text function call to the template.

I assume this means removing the g-> text function calls? This is not done yet.

The rest of the changes have been implemented, and the module seems to function properly, so at present I'm assuming I've done it right. However, I've only tested to see that the XML was created properly and updated along with the gallery, nothing else yet.

Lastly, thanks Bharat, for taking the time to do such a thorough review of the code, it gave me further insight into how the G2 API functions and is to be used.

Best regards,
G.[/]

[/]

[/]

[/]

[/]

rss-module-0.2.3.tar.gz

CHANGELOG:
----------
 * 2005-01-11: 0.2.3 released: now validates, some bugs removed
 * 2005-01-11: Minor code layout/comment cleanup
 * 2005-01-11: Fixed PHP syntax error in RSS title display
 * 2005-01-11: Added creationTimeGMTOffset to RSSItem.tpl in order
               to show pubDate in GMT and comply with RSS 2.0 and RFC 822
 * 2005-01-11: Used getHttpDate() instead of time() in RSS.tpl in order
               to show lastBuildDate in GMT and comply with RSS 2.0
               and RFC 822[1]
 * 2005-01-11: Set default mail address for comments without one in order
               to comply with RSS 2.0
 * 2005-01-11: Added e-mail to <author> in order to comply with RSS 2.0
 * 2005-01-10: Fixed a syntax error in the resulting XML (<item>s not
                                                          inside <channel>)
 * 2005-01-10: Modified the RSS links (added small RSS logo)
 * 2005-01-09: 0.2.2 released; now seems to work with CVS (minor bugs aside)

[1] Strictly speaking, it's RFC 2616 compliant, but the feed validates.
    Are there problems regarding RSS dates and RFC 822 vs. 2616?


TODO/ISSUES:
------------
 * Add option for NOT subscribing to ChildEntities
 * Add RSS links to front page as well (also when main.php is disabled)
 * Find out how to replace XML encoding (currently ISO-8859-1)
   and <language> with current G2 equivalents
 * Ditch Dublin Core metadata? No dc-elements are used (yet).
 * If several image resolutions exist of the same picture,
   which do we link to?
 * Can we link more directly to specific comments, instead of just going
   to the album they're in?
 * Should the current Gallery name be added to the feed title?

Comments are more than welcome. :wink:

BTW: Anonymous comments don't have an e-mail address, but they have to for the comments RSS feed, if we want it to validate. Now it defaults to

. Aside from the fact that default e-mail addresses Are Really Bad, what other options do we have?

Cheers,
G.

This is looking really good! It's getting pretty close. We still do need unit tests, and I don't think that I'm going to have a lot of time to write them myself (I'm now spending most of my evenings doing code reviews .. that's a good thing but it's not leaving me much time to code!). They're not all that hard; if you can take a shot at them I'll be happy to give lots of guidance.

General:

• All uses of RSS should be Rss since we're treating commonly used acronyms as words. I alluded to this in my last review but didn't really spell it out -- sorry! So RSS.inc should be Rss.inc and it sohuld contain RssView and the template variable its in should be $Rss and its template file should be Rss.tpl. You get the idea. Naming consistency is very important in loosely typed languages like PHP. I should have totally picked up on this in my first review but, uh .. it was late. I was tired. There was a tornado! Or something For this review, I'll use the names that you're currently using so that it's not confusing.

GalleryRssHelper.class:

• The GalleryRssHelper class was renamed, but the file should also be renamed to match for consistency.
• 70: should be indented to 12 columns
• 152: "retreave" -> "retrieve"
• 97,99: you're in a sprintf here, so why not replace $groupIdMarkers and $andPermission with %s and make them arguments to the sprintf instead? Same for $direction at the bottom. As long as we're using sprintf, let's use it all the way. The same applies to fetchLastGalleryComment()
• fetchLastGalleryComment() isn't the most appropriate name. How about fetchRecentGalleryComments() instead? And likewise for fetchLastGalleryPhotoItem()?
• in fetchLastGalleryComment, the way that you return interleaved GalleryComment and GalleryItem instances here leads to the unusual use of reset()/each() calls in RSS.inc. It's also inefficient since if you have 10 comments for 1 item you're going to add the item to the $entityIds array 10 times (once for each comment) then load it 10x extra times in GalleryCoreApi::loadEntitiesById(). A better approach would be:
  

          /* Get all of our comment ids and item ids */ 
          $entityIds = array(); 
          while ($result = $searchResults->nextResult()) { 
              $commentIds[] = $result[0];  /* keep these in order */
              $itemIds[$result[1]] = 1;    /* make a hash table of items */
          }
  
          /* Convert them to entities */ 
          if (sizeof($commentIds) > 0) { 
              list ($ret, $comments) = GalleryCoreApi::loadEntitiesById($commentIds); 
              if ($ret->isError()) { 
                  return array($ret->wrap(__FILE__, __LINE__), null); 
              }
              list ($ret, $items) = GalleryCoreApi::loadEntitiesById(array_keys($itemIds)); 
              if ($ret->isError()) { 
                  return array($ret->wrap(__FILE__, __LINE__), null); 
              }
              foreach ($items as $item) {
                  $itemIds[$item->getId()] = $item;
              }
          } else { 
              $comments = array(); 
              $items = array(); 
          } 
   
          return array(GalleryStatus::success(), $comments, $items); 
  

  Now we have all the comments (in the order that we wanted them) and we have all the items that the comments will refer to (unordered, but we don't care about the order). Then in RSS.inc:

          if ($entity == null) { 
              $comments = array(); 
          } else { 
              list ($ret, $comments, $items) = 
                  GalleryRSSHelper::fetchLastGalleryComment($itemId, $maxItems); 
              if ($ret->isError()) { 
                  return $ret->wrap(__FILE__, __LINE__); 
              } 
          } 
   
          $RSS['items'] = array(); 
          foreach ($comments as $comment) {
              $RSSItem = array(); 
              $commentMemberData = $comment->getMemberData(); 
              $itemMemberData    = $items[$comment->getParentId()]->getMemberData();
    // (rest is the same)
  

  This way we iterate over the comments, and then when we want to get the parent item's data, we grab the parent from the parent's hash map and use it.

RSS.inc

• 53,63,129: multiline comments should be in the form:
  

  /*
   * line 1
   * line 2
   */
  

• 120: use ' instead of "
• 134, 141: these strings need to be localized. In general, concatenating strings like this is going to make it very difficult on the localizers because they prefer to work with the whole block of text, not little bits of it. But for now you can do: $RSS['title'] = $module->translate(array('text' => '%s (Photos)', arg1 => $RSS['title'])), etc.
• 256-258: following up on my prior review (and the responses) you should use:
  

  foreach ($children as $keyComment => $comment) {
  

  here instead.

• 286: use ' instead of "
• 208-223, 293-308: the XML rendering is duplicated in your two render methods. Have your methods return the $RSS object, then create and render the template in renderImmediate() and you'll save some code duplication.

RSS.tpl

• <description>{g->text text=$RSS.description}</description> should be <description>$RSS.description</description> since the description is pure content; it can't be localized. Anything in {g->text} blocks must be a constant that can be separated out and passed to localizers for translation. Same for language, docs and generator, they should be:
  

      <language>en-us</language> 
      <docs>http://blogs.law.harvard.edu/tech/rss</docs> 
      <generator>$RSS.generator</generator> 
  

  language and docs are constant. They can't be translated. generator is pure content from the user like the description.

RSSLinks.tpl

• Indentation in HTML files is two spaces, so it should be like this:
  

  <div>
    <ul>
      <li>
        ..
      </li>
    </ul>
  </div>
  

• The <img> urls should be:
  

  {g->url href="modules/rss/images/rss.gif"}
  

  which means that you don't need $RSS['moduleUrl'] in module.inc

• Extra blank lines can be deleted (so that we send less bytes to the browser).

RSSItem.tpl

• description, email, author, albumTitle should not be in {g->text} blocks

module.inc:

• autoConfigure() should not set the version. We used to do that a while back but I moved all of that up into the GalleryModule class. Look at the zipcart or netpbm modules for an up to date example of how autoConfigure should look. Basically you can delete all version related lines and keep everything else
• 99: use /* instead of /**
• 169-170: inconsistent whitespace on these two lines
• 172: moduleUrl can be deleted (as I mentioned above)

[/]

[/]

[/]

[/]

[/]

[/]

[/]

geddeth: regarding the encoding: Gallery ensures that the encoding is always UTF-8 (at least, the Global template seems to assume so.) Therefore, iso-8859-1 can simply be replaced with utf-8, or, if you prefer, left out of the prolog altogether (making it <?xml version="1.0" ?>.) The default encoding for XML is utf-8, so leaving it off is the same as changing it.

I don't quite understand. In the beginning of your post, you suggest it be altered to foreach ($comments as $comment) { which seems to work fine?

The other issues you mentioned are all implemented now.

Also, is there anywhere I can look for directions regarding unit tests? I've searched the forums, read the Developer's guide and am now checking out source (core->AdminCreateGroupControllerTest among others), but I really feel a bit in the dark here, possibly because I've never worked with XP before.

I'll keep cut'n'pasting for now, maybe something will work.

Cheers,
G.

This is looking great! Looks like you rolled in all of my suggestions and are pretty close to the end. My review comments are of a much more subtle nature now. I think that we're getting pretty close to the point where we can commit this. I think that will make everybody very happy

General

• Detect if the comment module is active.
• Add yourself as an @author everywhere.
• I get warnings if I try the comment feed when I have no comments. Make sure that your system is configured to be strict according to our dev env spec so that you see these too.
• Comments RSS won't work if the comments module isn't active. The easy fix for this is to disable the comment RSS button if the comment module isn't around. The quick and dirty way to do this is to try to detect the presenve of GalleryCommentItem, which you can do by asking the factory for it:
  

  list ($ret, $comment) =
     GalleryCoreApi::newFactoryInstance('GalleryEntity', 'GalleryComment');
  if ($ret->isError()) {
     // return $ret->wrap..
  }
  if (!isset($comment)) {
     // no comment module
  }
  

  The long term right solution for this is to create an interface in the GalleryComment module and move the fetchRecentGalleryComments API method into it, then create an implementation of that interface and publish it. This is better because it means that the comment module can change around as much as it wants, and you don't have to try to keep up with its database structure. Let's go with the quick hack for now and then after the RSS module gets committed we can start the process of moving the API method over. It won't take all that long, but it's an easy thing to do afterwards.

AdminRssControllerTest.class

• Instead of doing
  

  $this->assertEquals(array(GalleryStatus::success(), $numberOfItems), 
   GalleryCoreApi::getPluginParameter('module', 'rss', 'numberOfItems')); 

  you should do:

  list ($ret, $savedValue) = GalleryCoreApi::getPluginParameter('module', 'rss', 'numberOfItems');
  if ($ret->isError()) {
    return $this->failWithStatus($ret->wrap(__FILE__, __LINE__));
  }
  $this->assertEquals($numberOfItems, $savedValue);

  It's a better pattern and does the error handling correctly. I used to do it the way you have above, but I've been updating that code wherever I find it.

• Add a test where form[numberOfItems] = -5. What should happen?
• Add a test where form[numberOfItems] = some random string (eg, "foo"). What should happen?

AdminRss.inc

• 49: $error is going to be empty (you just defined it above as empty) so there's no point in checking it here.
• 63: You can delete the "$results['return'] = 1" line altogether.
• When you write the tests I suggest above, I think you'll realize that you have no error checking in your controller and are putting whatever the browser gives you right into the database. This is a bad idea, and the new unit tests should help make sure that it doesn't happen.

GalleryRssHelper.class

• Both these helper methods should have unit tests. You can do this pretty easily by creating a little mini tree of albums, data items and comments, then calling the helper methods with the root album id and asserting that you get the right data back. Try removing view permissions from some of the items and make sure that they don't show up in the output. These tests become what we call an "executable design document" for your helper class -- they define the inputs and outputs for your method. Typically we try to write one test that covers the 80% case (all the standard stuff) then one test each for individual edge cases (invalid $itemId, the cases when there are no comments, no photos, etc). Then later on when we refactor this code (which we probably will -- it happens sooner or later) we'll know that we didn't break anything. Look at the setup method in modules/thumbnail/test/phpunit/CustomThumbnailOptionTest.class to see how you can create an album with a GalleryPhotoItem and a GalleryUnknownItem in it. Create a mix of those, maybe some sub-albums and then look in modules/comment/test/phpunit/CommentSearchTest.class to see how to create some comments. If the comment module isn't active, of course this is going to fail.
• I really like how you used the %1$s notation in your sprintf() calls -- I hadn't thought to do that -- very clever!
• in the SQL in fetchRecentGalleryPhotoItems you don't need to join through the GalleryEntity table. If it's in the GalleryPhotoItem table then you're all set. So basically you can convert all references to GalleryEntity to GalleryPhotoItem and you're all set. The SQL would look like this:
  

              SELECT DISTINCT 
                [GalleryPhotoItem::id], [GalleryEntity::creationTimestamp] 
              FROM 
                [GalleryPhotoItem], [GalleryPermissionMap], 
                  [GalleryItemAttributesMap=1], [GalleryItemAttributesMap=2] 
              WHERE 
                [GalleryPermissionMap::itemId] = [GalleryPhotoItem::id] 
              AND ( 
                      [GalleryPermissionMap::userId] = ? 
                      OR 
                      [GalleryPermissionMap::groupId] IN ( %1$s ) 
                  ) 
              AND 
                %2$s > ? 
              AND 
                [GalleryItemAttributesMap=2::itemId] = ? 
              AND 
                [GalleryItemAttributesMap=1::parentSequence] LIKE %3$s 
              AND 
                [GalleryItemAttributesMap=1::itemId] = [GalleryPhotoItem::id] 
              ORDER BY 
                [GalleryEntity::creationTimestamp] %4$s, [GalleryPhotoItem::id] %4$s

  I tested this out locally and it seems to do the same thing. This is the kind of refactor that's really easy to do after you have unit tests because if the unit test is well written, then you can tinker with the SQL as much as you want as long as the test passes.

• 138: should be indented to 16 columns
• in fetchRecentGalleryComments() I think you can also get away without joining through the entity table. Where you use [GalleryEntity::id] you can use [GalleryChildEntity::parentId] instead. I didn't try this out locally, but I can't think of a reason why it won't work.
• All the error returns in fetchRecentGalleryComments() are still returning only 2 args, instead of 3 which means that if there is an error the calling code in Rss.inc will bomb.

Rss.inc

• 54,55,56 (and other places): in multiline comment blocks the *'s should line up:
  

  /*
   * like this
   */
  

• 105,106,205,206,214,215,263,264,277,278: the entity data should already be utf8 entities so unless I'm missing something, you don't need to call htmlspecialchars() on it here. Try putting something like "<my title>" into the title of an album and then viewing the RSS feed to see what I mean
• 129: should be the multiline comment block style shown above
• 177: the phpdoc should reflect that you're returning two values now
• The error returns in both _renderXxx() methods should be returning an array now
• the for() loops in _renderImmediatePhotos() and _renderImmediateComments() should both have a $gallery->guaranteeTimeLimit(5) in them to make sure that they don't run out of time while rendering.

module.inc:

• 123: avoid catching and swallowing errors unless you know *exactly* why the error was thrown. Even then you have to do this with care. If there's an error in that call, you should let it bubble up to the framework and it will Do the Right Thing. Part of why you're getting this error is probably because $itemId isn't set to anything in some cases. See my next comment.
• in loadSystemContent(), the 'itemId' param won't always be set because it's not in the url for the top of your Gallery. If it isn't set, you should load the root album id instead. See GalleryView::_getItem() for an example of how to do that. This will give you the buttons on the main Gallery page, too.
• in loadSystemContent() you fetch the moduleParams but don't use them. This is a high-traffic method, so you should aim to streamline it where possible.
• If the $entity isn't an GalleryAlbumItem, then $tpl will be undefined and will give a warning when you try to return it.

RssItem.tpl

• Clever use of the GMT offset in your timestamp format!

[/]

[/]

[/]

[/]

[/]

[/]

[/]

i have downloaded this module,
but how can use it ?
there is no rss.php file.
who can help me ?

i want to use gallery2 in plog. In gallery1.44, there was a rss.php file in gallery folder. and i can use rss.php to get some album items in my plog.
but in gallery2,things changed.

on this website, there is a menu on the upper left corner. click on "Download Now!" and in the G2 paragraph, click on jmullans nightly snapshots link.
Download the most recent nightly snapshot of gallery2 and there you are.
If your current version is newer than G2 alpha 2 (or was it 4?),you can upgrade your current installation. If it is older, you'll have to install everything again. How to upgrade is described in the forums.

Wanted to download 'rss-module-0.2.4.tar.gz', but cannot connect to the server.
anyone out there who can e-mail me or provide it for download?

thanx in advance

RaVen

lixp, you should probably just not worry about it until its included in the g2 releases. It looks like the module wants an older version of module api, so i'd suggest just not worrying about it.

much love homey. ttys

I have taken this over, the two other who have worked on it have donated the code to us.

I will most likely be redoing a majority of the code, and my goal is to be able to support any type of rss feed (0.8, 0.9, 2.0 ... etc).

I would also like to let the feed be customizable. I begin work this week, so if you have any ideas or comments please get them to me sooner rather than later.

I really don't have much experience with RSS, but I think I can make this work for everyone.

Thanks

You can update the RSS module to conform to the latest API. We document all of our API changes so you have to go through the module and figure out what needs to be changed to conform to the new APIs. You don't need to wait for G2 final for this, you can fix it today.