code wise it seems good. We do need to think about the issues we are trying to solve with adding this. I want to make that whatever we pull down is the most helpful.

One idea I remembering talking about is instead of just getting some news stories, it could get the latest application version number from krita.org (4.1.1 right now) and compare it to the application's version. We could tell people there is an update. It could also potentially get back a few of the newest news posts along with that check.

With the new download page, we do have special variables where we store the current version number. Maybe I could expose that so the web request could pull that down. WordPress has a REST API that returns JSON. I am not sure if we have any C++ classes to help return JSON.

The end URL would be this: https://krita.org/wp-json/wp/v2/pages/592

I need to change WordPress a bit so it returns the extra custom fields I added. I think those are fields are private by default. It could return version number and release notes in that response. Not sure what people's thoughts are with that.

In terms of policy around the URL I can think of two ways to solve this:

1. Through Wordpress' own caching system, like we use for when Krita is released. In theory this makes most hits effectively static so it should be able to handle things.
2. Change Krita.org to be behind a caching service like Incapsula, which will scale out without any need for change from our side, as long as we make the page cachable.

In terms of modifications to Wordpress, please keep those away from the core as otherwise they'll be blown away when we do the next update.

• signature.asc833 BDownload

• signature.asc833 BDownload

Hi, @rempt!

Is it expected that double-clicking on a news item does nothing? I though it would open a browser for me...

UPD:

Ah, the problem is not in the patch, but in the fact I run Krita in a container where there is no web browser, so it is not a bug.

Weird, looks like sending email with a signature results in the signature being appended, instead of the comments...

This is probably a limitation of Phabricator's email bridge, which can't handle both attachments and inline comments at the same time.
(I'd suggest top posting as well in replies to Phabricator, I don't know how clever it is at handling this)

I just updated the rest API, so you can now get the release version, and a URL for a link to the release notes.

https://krita.org/wp-json/wp/v2/pages/592

It looks like this in the response...

"meta":{"Version Number":["4.1.1"],"Release Notes URL (type 'false' if none)":["https:\/\/krita.org\/en\/krita-4-1-release-notes\/"]}

The release notes key is kind of messy, so I can clean that up if it makes it easier. I wasn't thinking about this type of thing when I originally came up with that key. I think we can get to just about any field on the website if we need to.

If you can find a C++ class that returns JSON from the request, you should be able to grab this

In D14947#312771, @bcooksley wrote:

This is probably a limitation of Phabricator's email bridge, which can't handle both attachments and inline comments at the same time.
(I'd suggest top posting as well in replies to Phabricator, I don't know how clever it is at handling this)

I've seen it quote correctly :-).

In any case, my two replies again. I've been sick this week, so I'm rather late.

On dinsdag 21 augustus 2018 07:39:22 CEST you wrote:

bcooksley added a comment.

In terms of policy around the URL I can think of two ways to solve this:
 
1. Through Wordpress' own caching system, like we use for when Krita is

released. In theory this makes most hits effectively static so it should be
able to handle things.

That would mean we'd have to remember to clear the cache manually after
posting a new story, right? That's certainly doable.

2. Change Krita.org to be behind a caching service like Incapsula, which will scale out without any need for change from our side, as long as we make the page cachable.

Would that make tracking the website usage itself harder or impossible?

In terms of modifications to Wordpress, please keep those away from the

core as otherwise they'll be blown away when we do the next update.

Yes, I wasn't thinking of trying to make changes to the wordpress install

On dinsdag 21 augustus 2018 01:35:20 CEST you wrote:

One idea I remembering talking about is instead of just getting some news

stories, it could get the latest application version number from krita.org
(4.1.1 right now) and compare it to the application's version. We could
tell people there is an update. It could also potentially get back a few
of the newest news posts along with that check.

Well, my main goal wasn't telling people when there's a new update, but having
a way to connect them to the community by showing news. And also telling
people we're doing fund raisers and so on.

With the new download page, we do have special variables where we store

the current version number. Maybe I could expose that so the web request
could pull that down. WordPress has a REST API that returns JSON. I am not
sure if we have any C++ classes to help return JSON.

The end URL would be this: https://krita.org/wp-json/wp/v2/pages/592
 
I need to change WordPress a bit so it returns the extra custom fields I

added. I think those are fields are private by default. It could return
version number and release notes in that response. Not sure what people's
thoughts are with that.

For updates, I think it would be better to show a popup that tells people
there's an update and then have a link to the download page. (Not start
downloading automatically, because I want them to see the donation page
again.)

In regards to caching - yes, it would mean we'd use the existing Clear Cache mechanism when posting new articles/stories.

For Incapsula, as Krita.org uses stats.kde.org any caching of the site itself, even through the use of services like Incapsula, won't have any impact on that data.

The news does take quite a bit of space. One idea is we could start using a stacked widget thing to have sections of this (mockup below). I think we discussed that previously in the case we start getting a lot of stuff.

If we put the news in its own section, we could show more information like the date and maybe the post excerpt (short summary) . That would be pretty helpful to see. For the URLs to the site, I wonder if we could append a bit of text to them to check how many people are using it. It would be neat to see if people use it. Something like this.

https://krita.org/en/item/interview-with-margarita-gadrat/?pk_campaign=app_dashboard
where "?pk_campaign=app_dashboard" is appended to every URL.

reference: https://matomo.org/docs/tracking-campaigns/

We can not worry about the update Krita portion from my last comment, but I will still leave the krita version stuff on that callback. I think we can at a later time add a "check for updates" menu item or button.

Yes, I want to make a separate diff for a "there's a new version, go to the dowload page" dialog. I'm also wondering whether this widget shouldn't be in a separate tab, and all the stuff needed to make a fancy delegate showing title, date, summary and maybe even some graphics is there. The user string, btw, should already be enough to track traffic from Krita, though I explicitly did not add anything to make them per-user unique.

Argh, that's only the diff compared to the previous diff. Please check the rempt/news-widget branch.

I'll push this to master now; I also want to push it to krita/4.1.