TODOs

[em92]

• Move all wiki pages except "Public Hosts" to repository. Reasons:

  1. There are PRs (at least [BridgeFactory.php] Add RSSBRIDGE_WHITELIST environment variable support #2058 and [Config] Add custom config location #2098) that require editing certain wiki pages, when merged. That is not convenient.
  2. If something awful happens to this repository (banned for example), it is easy to migrate to another
     Responsible: @em92

• Move release preparation scripts to contrib/prepare_release directory. As for now, instructions how to prepare release is hidden in one of draft releases
  Responsible: @em92

• (Done [core] Support for bridge maintainers' donation URLs #2102) In top of HTML format preview add link to donate bridge maintainer. Discussion about donation: About donation #2063

• (Done [BridgeCard] Make HTML default, remove other buttons #2101) Make HTML format as default feed format. Reasons:

  1. Promote donating bridge maintainers (see above)
  2. When filling values and press enter, redirection to Atom feed happens. Firefox does not recoginize it, and suggests to download file, Chromium-based browsers show xml as plaintext. Making HTML as default will have better UX.

• Allow to use environment variables instead of config.ini.php. Reference: How should authentication through config.ini.php be used on Heroku? #2071 (comment)

• Add hidden contexts which are not shown in bridge card. Possible usages:

  • Hiding deprecated context
  • Use context to generate permalink to media, which original links expire. Useful for resolving [TelegramBridge] Images in old posts do not load due to media URLs with expiration date #1901 and Instagram-Bridge failed to due deprecated IG API #1818

• Add section in main instance page for using detect action

[Added on May 8, 2021]

• (Done [BridgeImplementationTest] Implement feature for testing detectParameters method #2147) Implement running test cases to check correctness of detectParameters behavior. Reason:
  Bridges that include "detectParameters" method must also have test samples like "link" -> "bridge parameters".
  Example PR where I tried to test it: [YoutubeBridge] Add detectParameters #2108
  As possible solution - make modification to BridgeImplementationTest.php that would execute testing those samples, that are defined in bridge like this

const TEST_DETECT_PARAMETERS = array(
  'https://www.youtube.com/playlist?list=PL0lo9MOBetEFEzIm3OP9_5jtkilBobdKB', array('p' => 'PL0lo9MOBetEFEzIm3OP9_5jtkilBobdKB'),
);

[Added on June 26, 2021]

• Correct error handling of curl related errors. Like this one: Twitter @PKEconSoc failed with error 0 #2157

[Bockiii]

Love the idea!

About the release preparation scripts: You should include a github action to create a multiarch container that also builds arm versions of rss-bridge. I've prepared something in https://github.com/Bockiii/rss-bridge/tree/multiarchversion . With QEMU, it's really easy to build and manage. You can also configure an action to not trigger on every commit (as it is right now in my example) but on every release. hit me up if you want me to do that. I'm not a fan of the release cycle of rss-bridge tbh, so maybe we should talk about the releases first. There were only 2 releases in 2020. That means you will drive people away from the official releases and into self-maintained repos and instances. Maybe a "testing" branch to do PRs against and then a merge into master after testing and then just use the master branch as the latest version.. idk, but I cannot believe I am the only one who has an issue with 2 releases a year.

I will take a swing at the environment variables task. I will open a "working on it"-PR so people can interact and then, when the feature is done, merge all the changes into one, good commit.

[Bockiii]

@em92

For "Make HTML format as default feed format"

Would it make sense to get rid of the whole link-row on the front page and instead go for a "Show Feed" button that leads to the html feed? This will also stop the confusion about getting the atom/mrss link for example (on the front page, you cant right-click on the button and say "copy link location", you can do that on the atom/mrss buttons on the html-view though).

I think it makes the whole navigation a little more intuitive

[Bockiii]

As you can see, I switched the bridgelist behavior to only show the HTML view as default (see #2101) and I added Donation URL Support (see #2102). I'll wait for feedback before I go for another topic.

[Bockiii]

@em92 for the wiki topic: are you looking into readthedocs or gitbook? If you move to a new process, it might be worth looking into that. Both are free for open source projects.

[em92]

for the wiki topic: are you looking into readthedocs or gitbook? If you move to a new process, it might be worth looking into that. Both are free for open source projects.

@Bockiii, I planned using markdown files on repository. They are simple and no need to host them.

About the release preparation scripts: You should include a github action to create a multiarch container that also builds arm versions of rss-bridge.

By the word "release" mean those ones also I would call them "release preparation instructions and a emacs script". Docker images are different things and they are updated on every commit in master. https://hub.docker.com/r/rssbridge/rss-bridge.

I'm not a fan of the release cycle of rss-bridge tbh, so maybe we should talk about the releases first. There were only 2 releases in 2020.

That is long story for explanation. I will describe it later in discussion.

[Bockiii]

@em92

@Bockiii, I planned using markdown files on repository. They are simple and no need to host them.

https://medium.com/@Mister_Gold/stop-using-markdown-for-documentation-5bda05ad17e3

Markdown has it's moments to shine, but code documentation is not really one of them. rst would be the better choice (readthedocs uses rst for example. See the readthedocs example:
View: click
Source: click
Github webview: click

You can also host that in the repo and not use readthedocs at all since the webviewer from github supports rst. Just dont use md :)

Docker images are different things and they are updated on every commit in master.

Ah, sorry, didn't see that yet as I've been using rssbridge basically since April 28 :). If they update on every commit, I can put in the PR to give you multiarch (armv7 and armv8 which are basically all raspberry pis except for the very first one) immediately. You then need to configure your dockerhub autobuilds but we can discuss that in the other PR then.

That is long story for explanation. I will describe it later in discussion.

Okay. If the docker container uses the latest master, the releases are not that important to me :)

[em92]

Added task on [Added on May 8, 2021]

[em92]

Added task on [Added on June 26, 2021]

[em92]

Closing as seperated to different issues.