Tracker log

An overview of recent activity in the tracker.

Maurits van Rees added a new response to »update_feed_items changes modification date of previously existing feed items«:

Target release: None → 2.0.4.
Added 44 day(s) ago.

Maurits van Rees added a new response to »Provide Plone4 content-core metal slot (for compatibility with collective.blog.view)«:

This fix is in 2.0.5.

2.0.7 is the most recent release (made today).

Target release: None → 2.0.5.
Added 44 day(s) ago.

Maurits van Rees added a new response to »UnicodeDecodeError in feed parsing«:

This fix is in 2.0.5.

2.0.7 is the most recent release (made today).

Target release: None → 2.0.5.
Added 44 day(s) ago.

Maurits van Rees added a new response to »Post content in xml needs more careful approaches«:

2.0.7 has been released with this fix.

Target release: None → 2.0.7.
Added 44 day(s) ago.

Maurits van Rees added a new response to »BadRequest Error if enclosure already exists«:

2.0.7 has been released with this fix.

Target release: None → 2.0.7.
Added 44 day(s) ago.

Domen KoÅ¾ar added a new response to »BadRequest Error if enclosure already exists«:

Thanks!

Added 44 day(s) ago.

Maurits van Rees added a new response to »BadRequest Error if enclosure already exists«:

No, that works fine. I have just tested it.

But when one entry has two enclosures that have the same href, then this BadRequest error will occur.

Fixed in r247577.

Issue state: Unconfirmed → Resolved.
Added 44 day(s) ago.

Domen KoÅ¾ar added a new response to »BadRequest Error if enclosure already exists«:

This only happened once and since it was on production, I didn't have time to investigate what exactly went wrong. Cronjob just started failing.

What was happening was that invokeFactory could not create enclosure. If I remember correctly this happened due to two posts having the same signature for enclosure. Is that possible to conflict?

Added 44 day(s) ago.

Maurits van Rees added a new response to »BadRequest Error if enclosure already exists«:

That would be strange. When updating an existing feed item, feedfeeder calls the replaceItem method of the folder, which removes the existing item and adds a fresh one. This fresh one of course does not contain any enclosures.

Are you using any patches?

Or are you just guessing that this happens in theory? I got confused myself anyway, as I wondered during testing where the previous enclosure had gone. :-)

Responsible manager: (UNASSIGNED) → maurits.
Added 44 day(s) ago.

Maurits van Rees added a new response to »Post content in xml needs more careful approaches«:

Sorry for this late reaction.

I cannot reproduce this, also not with the feed as it was at the moment you reported it (I downloaded it at the time).

But it makes sense, so I have applied your fix (slightly changed). Fixed in r247572.

Thanks.

Issue state: Unconfirmed → Resolved.
Responsible manager: (UNASSIGNED) → maurits.
Added 44 day(s) ago.

New issue »BadRequest Error if enclosure already exists« added by Domen KoÅ¾ar

If enclosure already exists, invokeFactory will return BadRequest error since it expects unique id

Commit: https://github.com/[…]/9b674965f2328a0091b16f8c3dd0cdfba4026425

Added 76 day(s) ago.

New issue »Post content in xml needs more careful approaches« added by Domen KoÅ¾ar

Two issues, if content has text/xhtml content type:

* if there is no wrapper tag for the content, minidom parser fails
* archtypes have no idea about xhtml by default, so following line fails https://github.com/[…]/utilities.py#L61

Problematic feed: http://www.tablix.org/~avian/blog/atom.xml
Fix (commit): https://github.com/[…]/db8fd8f7d1322ee15e9f1d223187ba96e2808315

PS: commit is not really a fix for upstream, as I have close to zero experience with feeds in general

Added 76 day(s) ago.

Maurits van Rees added a new response to »Update breaks on some feeds«:

Released 2.0.6 with this fix.

Target release: None → 2.0.6.
Added 130 day(s) ago.

Maurits van Rees added a new response to »Update breaks on some feeds«:

Patched both location on trunk in r244981.

Issue state: Confirmed → Resolved.
Added 130 day(s) ago.

Domen KoÅ¾ar added a new response to »Update breaks on some feeds«:

Interesting, as I am using trunk version. Maybe it's not getting enough entries.

The patch also needs to affect isHTMLEnclosure method, otherwise it looks good to me.

Added 131 day(s) ago.

Maurits van Rees added a new response to »Update breaks on some feeds«:

I have just tried it on trunk with that feed and it works fine here. But I do not even get to the point where link.type is getting called (line 346 in utilities.py).

We can still guard against this error though. I would commit the following fix, but svn.plone.org is currently down::

  $ svn diff
  Index: Products/feedfeeder/utilities.py
  ===================================================================
  --- Products/feedfeeder/utilities.py (revision 244438)
  +++ Products/feedfeeder/utilities.py (working copy)
  @@ -343,7 +343,13 @@

           file.flush()
           file.seek(0)
  - obj.update_data(file, link.type)
  + try:
  + link_type = link.type
  + except AttributeError:
  + # Some links do not have a type.
  + # http://plone.org/products/feedfeeder/issues/39
  + link_type = 'application/octet-stream'
  + obj.update_data(file, link_type)
           file.close()
       except urllib2.URLError:
           # well, if we cannot retrieve the data, the file object will

Issue state: Unconfirmed → Confirmed.
Responsible manager: (UNASSIGNED) → maurits.
Added 131 day(s) ago.

New issue »Update breaks on some feeds« added by Domen KoÅ¾ar

Following feed causes trouble: http://slovenski-prevajalci.blogspot.com/[…]/default

Traceback:

2011-10-02 12:12:27 ERROR Zope.SiteErrorLog 1317550347.730.240197045982 http://127.0.0.1:8080/Plone/planet/update_feed_items
Traceback (innermost last):
  Module ZPublisher.Publish, line 126, in publish
  Module ZPublisher.mapply, line 77, in mapply
  Module ZPublisher.Publish, line 46, in call_object
  Module Products.feedfeeder.browser.feed, line 46, in __call__
  Module Products.feedfeeder.browser.feed, line 43, in update
  Module Products.feedfeeder.utilities, line 98, in retrieveFeedItems
  Module Products.feedfeeder.utilities, line 295, in _retrieveSingleFeed
  Module Products.feedfeeder.utilities, line 346, in updateWithRemoteFile
  Module feedparser, line 356, in __getattr__
AttributeError: object has no attribute 'type'

One of the link does not have link type information, I would suggest to fallback to "unknown" or something similar in that case

Added 131 day(s) ago.

Maurits van Rees added a new response to »Provide Plone4 content-core metal slot (for compatibility with collective.blog.view)«:

Added our own documentbyline viewlet in r244107.
Using a different template in Plone 3 and 4 in r244109.
I think that fixes this.

This will be in the soon-to-be-released 2.0.5 release.

Issue state: Unconfirmed → Resolved.
Responsible manager: (UNASSIGNED) → maurits.
Added 160 day(s) ago.

Maurits van Rees added a new response to »Error on adding new feed item«:

Hm, this is in a feedfeeder patch that is in gomobile.supporter. But I will have a look.

Ah, Mikko fixed this already on gomobile.supporter trunk in revision 911; so this should be fixed with the next gomobile.supporter release.

Issue state: Unconfirmed → Resolved.
Added 160 day(s) ago.

Maurits van Rees added a new response to »Error when updating catalog with feedfeeder items«:

I tried again but could not reproduce it. The field you mean is 'objectInfo'. I checked the code related to that but did not find anything suspicious. Sorry, but I am going to reject this issue as I cannot reproduce it. Ideas for how to reproduce it are of course very welcome.

Issue state: Unconfirmed → Rejected.
Added 160 day(s) ago.