Concatenate or just link text input to download block

[anewuser]

I've made this to monitor new subtitles:

https://www.pipes.digital/pipe/j1O4Ve9d

Film pages have clean URLs like:

https://subscene.com/subtitles/metropolis https://subscene.com/subtitles/the-general-1926

To avoid having to create new pipes for every new film I want to monitor, using a dynamic input block sounds a good idea.

However, input blocks can't be linked to download blocks. If you believe that letting people input full custom URLs could cause problems, what about having a way to at least concatenate a text input with a download block , so that I could have a download block like this:

https://subscene.com/subtitles/ + text input (e.g. metropolis, the-general-1926 etc.)

[onli]

There is no deeper reason why text input blocks can't be connected to download blocks, this is merely a bug. I will look into this.

[onli]

This will work now. Be sure to manually reload the page to clear the cached javascript.

[anewuser]

Thank you!

[anewuser]

Can you tell me why this is giving server errors? https://www.pipes.digital/pipe/j1O4Ve9d

Entering the same URL in the download block (without the text input) worked.

[onli]

I see nothing wrong with it, apart from that currently the text input block is not connected to the download block. Might it be just that?

If you just disconnected the text input block later on, could you please share the pipe? It would make debugging easier.

[anewuser]

It seems there was some problem when I saved the pipe with text inputs (at least with the combination of block types I used in this pipe), because I did connect those blocks, and they were reset to unconnected twice... then it happened again with a second text input I added.

I'm not sure if this problem was on my side, since Firefox is set not to keep any cache after closed, and I restarted it a few times during this process. I'll report if anything like that happens again.

Anyway, the feed is now working: https://www.pipes.digital/pipe/j1O4Ve9d :)

There's only a minor thing: the input seems to be case-sensitive:

https://www.pipes.digital/feed/j1O4Ve9d?Subscene+link=https%3A%2F%2Fsubscene.com%2Fsubtitles%2Fmetropolis&Language=Italian

https://www.pipes.digital/feed/j1O4Ve9d?Subscene+link=https%3A%2F%2Fsubscene.com%2Fsubtitles%2Fmetropolis&Language=italian

[onli]

I'm happy it works now.

I'll report if anything like that happens again.

Please do. That has the potential to be a very annoying bug, but I did not see it at all so far.

There's only a minor thing: the input seems to be case-sensitive:

I would assume that comes from the subscene website, or is that one not case sensitive?

[anewuser]

The "Language" parameter is given to a filter block. I made it so that Pipes downloads the entire page from Subscene and then adds to the feed only the language you entered.

I mean that entering either "Italian" or "italian", or "Trump" or "trump" in your own example, should work:

https://www.pipes.digital/feed/14OE65qg?feed=http%3A%2F%2Frss.nytimes.com%2Fservices%2Fxml%2Frss%2Fnyt%2FHomePage.xml&filterterm=trump

https://www.pipes.digital/feed/14OE65qg?feed=http%3A%2F%2Frss.nytimes.com%2Fservices%2Fxml%2Frss%2Fnyt%2FHomePage.xml&filterterm=Trump

[onli]

For the filterblock, they just are case sensitive. You can make them case insensitive by using a regexpression, by writing /keyword/i. See here: https://www.pipes.digital/feed/14OE65qg?feed=http%3A%2F%2Frss.nytimes.com%2Fservices%2Fxml%2Frss%2Fnyt%2FHomePage.xml&filterterm=/trump/i

[anewuser]

I see. Is there any specific reason why you don't want to make it case-insensitive by default when connected to text inputs? As an alternative, text input blocks could have a checkbox for this in the editor.

[onli]

It would be very hard to trigger case-sensitivity that way around. As it is now that just comes by default from supporting regexpression.

[anewuser]

Thanks for the replies!