Vanilla 1 is no longer supported or maintained. If you need a copy, you can get it here.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Feed Publisher

edited August 2008 in Vanilla 1.0 Help
Feed Publisher
«134567

Comments

  • Uploaded version 0.0.2 of Feed Publisher.
  • Uploaded version 0.0.3 of Feed Publisher.
  • 0.0.3 fixes the Call-time pass-by-reference has been deprecated - argument passed by value; issue
  • Well done, Grahack. It's looking very good so far.

    One question:

    Is there an easy way to limit Feed Publisher to only publish RSS2 Feeds or only ATOM Feeds? I can easily see the benefits of having both types of feeds, but sometimes it's ideal to just offer one type of feed to users.

    I commented out the comma and the 'ATOM' in the "PublishedTypes" array in default.php, like this:

    $PublishedTypes = array( 'RSS2' //, // 'ATOM' );
    ...and it seems to have done the trick, but I'm not sure if that's the best way to do it or not. Can you clarify?
  • Yes it's exactly what I would have told you to do!
    And of course remove the atom lines in the categories_config.php file.
    I plan to move $PublishedTypes in a config file like I did for the categories_config thing. I was just waiting for someone to ask this question to decide to do so :)

    Maybe you don't have much time, but did you try to join the Assembla project?
  • Yes, I was able to register very easily with Assembla. Though, I've never used Trac before, and it seems rather cryptic on first glance. Not sure how to use it exactly.

    BTW, Trac/Assembla is definitely good for the maintenance and upkeep of the Add on, but I think a lot of Vanilla developers will benefit if the overall discussion for Feed Publisher is kept going right here on this forum.
  • Great!!! So it's possible!!! I just promoted you to the member status (I still have to investigate for what things you can or cannot do).
    You'll love Trac. If you have a question about Trac, feel free to create a ticket on our project with "trac use" as for the component.

    About the benefits for other Vanilla developers, we'll tell the community important things that we discovered. But specific FeedPublisher discussions between FeedPublisher developpers will occur on our Trac project. FeedPublisher USERS will be able to discuss on both (Vanila forums or Trac tickets, as they wish). What do you think?
  • It's just that the Vanilla Forums are so easy to use and all of the top developers who glance at many coversations each day are often extremely useful for helping with solving all sorts of issues. By branching off to another forum, it's going to limit the exposure of the development process to only those who have a vested interest with this Add-on. Personally, I think that will make things more difficult. I think we should try to have the general discussion here, and then use Trac to keep on top of the current tickets and code? I think the Trac forum would be ideal for just coordinating active and closed tickets. (I think MooTools uses Trac that way). Maybe we're saying the same thing. But, I just think that the main discussion for uncovering and finding solutions for issues should be here.
  • Agreed. Anyway, FP is not a huge thing. We won't face 50 problems at the same time. Or I hope so.

    So I begin now: what is left to do about feeds?
    • do authenticated feeds work well? A recent post by Skube says 'no'
    • is mod_rewrite thing solved
    • ...
  • I was never able to get authenticated feeds to work at all - it has been a show stopper for me. A solid solution would be greatly appreciated.
  • I know quite nothing about authenticated feeds, but I can learn.
    Would you please take the time to register on Assembla, and then I'll give you permissions to edit a dedicated wiki page ?
    I need you to describe the softs you use, the problems you encounter...
    Thanks.
  • Any chance of modifying this extension to provide an RSS feed for new topics (i.e. the first post in each thread) rather than every single message in a forum? For fairly busy forums it would allow people to view each new discussion in one feed, then subscribe to an individual topic's feed if they're interested in following the conversation.

    I'm not suggesting that you give up the all-messages-in-one-feed capability, but I think a new-topic feed would be a great addition.
  • <jedimindtrick="these_aren't_the_droids_you're_looking_for"> Ummm. never mind about my last post. It looks like it works that way already... I don't know what I thought I was looking at. </jedimindtrick>
  • Maybe the readme isn't clear enough, what do you think of:

    There are three different behaviours for the same (at first sight) links that appear in the panel.
    1. The link when inside a discussion (in comments.php pages) reports all posts in a discussion,
    2. the link appearing after whatever search (in search.php pages) reports the results to this search,
    3. and the link configured by hand (mostly categories config, so in the categories_config.php, only appearing in index.php pages) reports whatever you choosed (mostly the result of an empty search in topics INSIDE A PARTICULAR CATEGORY or even ALL CATEGORIES) like for example only the first posts in a particular category, or even all categories.
    Is it clear? Is is correct English? Should I copy-paste this in the dist files?
  • Hi!

    Which feed reader may I use, if I have feeds with authentification?

    Tiggr
  • You need some visual reminder that users could subscribe to feeds Icons like "Feed for categories", "Feed for discussions, "Feed for comments"
  • @ Tiggr
    I don't know which reader... What readers do you know? Which one have you already tried?
    I really need some help about this. Russlipton and you are officially invited ;) to complete the brand new 'authenticated feeds' page.

    @ Toivo
    mmmh, you mean different icons? Well I'm not good at visual things. If you give me nice little icons for discussion, search and category feed links, I'll try to make something with it.
    But did you see the tooltip: it's different for searches and topics, and the category feeds are configured by hand so you can choose the tip that you want. I personaly like consistent feed links, and find that the tooltip is enough, but maybe everyone will disagree...
  • Let's avoid mixing presentation into this Add-on. Each Vanilla forum is going to be styled differently (that's one of the great things about Vanilla). And, the default style for Vanilla is really just plain-text — as demonstrated by Mark's RSS Add-On. There's no reason to introduce icons that will only appeal to some people.

    The only thing we should do (if anything) is add a CSS hook to the different feed links. That way anyone can style the links as they please.

    For instance, the following class/hook would offer sufficient control for someone to easily customize the text or add a CSS image replacement on the link if they wanted to enhance it further:
    <a href="#" class="rss">RSS</a>
  • Ok Dan, thanks for your wise advice.
    I didn't want to force people using the image tag, only let it available through a config item. But this would have been too much again.

    So let's go with css. First, do we need a prefix, like 'fp_' (classes would be: fp_rss and fp_atom)?
    Second, to answer Toivo's idea, is it too much to distinguish the different types of targets.

    We would end with
    fp_rss_category, fp_rss_discussion, fp_rss_search,
    fp_atom_category, fp_atom_discussion, fp_atom_search.

    It's a lot, but not too much for me.
  • The tooltips are great.

    However, I'm pretty sure there isn't a need to distinguish the different targets as separate classes. All of the specific CSS hooks we need are already there in Vanilla.

    When you're on a discussion page, you have...

    <body id="DiscussionsPage">

    ...as a hook to target the RSS and ATOM feed links. When you're on a comments page the body tag is...

    <body id="CommentsPage">

    ...and when you're on a search page the body tag is...

    <body id="SearchPage">

    So, there's no need to get fancy and specific with the classes in the HTML. Everything can easily be targeted like this:

    #DiscussionsPage #Panel a.rss {color:blue;} #DiscussionsPage #Panel a.atom {color:yellow;} #CommentsPage #Panel a.rss {color:orange;} #CommentsPage #Panel a.atom {color:red;} #SearchPage #Panel a.rss {color:magenta;} #SearchPage #Panel a.atom {color:cyan;}

    I suppose you could use "fp_" as a prefix for Feed Publisher classes, but I don't think it's necessary. This Add-on won't work with any other RSS/ATOM add-ons, so there's really nothing to conflict with it.

    Honestly, I think everyone's going to be better off if we keep this simple -- just like Vanilla. Anyone who really needs to get fancier than that can make a simple modification on their own.
This discussion has been closed.