Dev looks good now w/ same article && section

...dupe ticket of this => https://phabricator.wikimedia.org/T351592

so yes, this API looks what I am looking for in regards to functionality.

Can we first address this:
Is the On-Demand API (docs link I gave prior) what you're looking for in regards to functionality?
It grabs the current version of a single article. That is what you're asking for yes?

The On-demand API offers single article response, instead of going through an entire project dump => https://enterprise.wikimedia.com/docs/on-demand/

@JArguello-WMF It's security and marketing related. Anything public facing that's not 'public' or that we don't want to rank in search engines and take away any keyword/keyphrase from our site and marketing efforts should either be password protected, or at an absolute minimum have noindex/noarchive meta robots tags to tell search engines to not index it.
The "shouldn't be running betas on prod domain subs" is we shouldn't be adding aforementioned non-public pages/tools/content to *.enterprise.wikimedia.com.

yeah the ID is just that, non-incremental. count is something we'd need to add to the API. I agree it's a nice addition.

has now been deployed to Prod. confirmed working as of this morning.

Found "enterprise" referenced in HF too but it's the free dumps https://huggingface.co/datasets/SaulLu/wikipedia_html_enterprise

In T343326#9168630, @JArguello-WMF wrote:

@creynolds has been asking.

👀

Errors in site editor:

We have date_created field now for some time. @JArguello-WMF review ticket pls

API consumers can use is_breaking_news field in Realtime API in production

Note that it's version.is_breaking_news

Dev has run course (manually x each step) and deployed good now.

In this case, I believe we don't currently have a way to know when that happens in order to fire an event... that technically would be the ticket and the event delivery endpoint is probably changing soon; offline convo; standby.

in debug found that manual plugin dir upload wasn't overwriting previous and file vars weren't in sync between plugins. closing as solved.

This one it seems: https://phabricator.wikimedia.org/T329496

@Alexander.lauie understood. ty

@Alexander.lauie that's fair and noted.

This will solve a current issue however we need to discuss user pool/group being directed tied to feature access, as most use cases will fit that case, however we're already at a point where sales is more dynamic than that.
At some point APIs/features and Support tiers/features would be options assigned to a user account as opposed to a user group assigning those. Just a different approach from init.

Context for reference.

• @HShaikh for DNS / IT specific help
• Amy Mueller for ZenDesk admin specific help

fixed. ty

Fixed. ty

installing the plugins manually right now

by "manually" you mean from the WP plugin repo via wp-admin and not the WME-repo held custom plugins right?

@Alexander.lauie think that's an issue in the lambda func sendCodeForgotPassword()?

For reference I just had AlexL add a single resp == "Input must not include spaces".
I'm also looking into sanitization philosophy outside of this ticket's intent.

@Alexander.lauie I thought what @Anna.bondar had in the email template was good. We should state their username clearly like that as it isn't inherently understood that the "HI {blah}" is their username to log in with... also don't need to target blank in anchor tag inside emails.

fixed, deployed to dev for Q/A, @Anna.bondar

MR added for @Alexander.lauie

Confirmed - thank you sir.

Moved font stack update to MR in https://phabricator.wikimedia.org/T311694

Can close this ticket due to https://phabricator.wikimedia.org/T311689

a "ghost image"?... 🤔 - who you gonna call? #ghostbusters

new changes to dash in here https://phabricator.wikimedia.org/T311694

new changes to dash in here https://phabricator.wikimedia.org/T311694

done? close?

Old - nuke @Protsack.stephan @Alexander.lauie ??

Old - nuke @AnnaMikla?

Old - nuke @AnnaMikla?

pretty sure this was/is done yeah? we have events firing in FP already

hey @Alexander.lauie on site we're using this fontstack - bumped it the other day to help w/ variances w/ MSEdge - this seems to have normalized it.

related ticket for dash for events https://phabricator.wikimedia.org/T311022

added another CNAME ticket that needs to be done by launch too https://phabricator.wikimedia.org/T310311

not that it's a huuuge deal but... www doesn't. Not too worried about that however; glad to have this redir setup! Thanks all

Looks good - send it! @Alexander.lauie

@Alexander.lauie The dashboard will be moving and changing by June and will have this new look. The amount of people that are even in the dashboard as it stands now and the frequency at which they're in there and how often those same people would be on our website looking at that page and notice the image representation is different is an extremely small number. I'm not worried about it causing issues. Let's just go ahead and make the change. Thank you sir

OK... evidently they were all updated to white.... which also means now the Products page 'dashboard' image needs to be updated. I know that's not part of this Original Ticket but @Alexander.lauie is that something we can get updated quick in this ticket ???

These are white background vs the dark/gradient bg on the originals but... i'm fine with it right now. I'll have design look and if they don't have major concerns with it we can push. Standby.

In T304555#7816155, @Arlolra wrote:

The parsercache isn't purged but, going forward, new revisions will link similarly