I stopped tagging with the move to REL branches.

Whoops, thanks for the reminder!
Just pushed the tag.

Sorry, totally missed this. Actually it is not related to ApprovedRevs but to the task in the mention.

Never thought of this
I've updated the source on packagist, many thanks!

I was trying to get wikiseo into the mediawiki packagist namespace, but to no avail.

Thanks for the report. When WikiSeoEnableAutoDescription is active, after a page has been edited, WikiSEO tries to generate a description by calling TextExtracts.
With Extension:Description2 deactivated can you check any of your pages with ?action=info and report if a description prop is listed there?

If it would help I can add more feature flags to enable/disable most things?

Smallish update. I'm now using this in production. SymfonyMailer has send around 8k Mails without a hiccup.
{F35871073}

This patch raises the required MW version to 1.39+ and PHP to 8.0+.

I think this was fixed a while back. At least when running php extensions/WikiSeo/maintenance/GenerateDescription.php --force 0 on MW 1.39 no such exception occurs.

Current implementation support:

• dc.identifier.wikidata
• author
• description
• title
• site_name

This is more or less expected, as neither OpenGraph nor Schema.org officially support svg images.

Sorry, I've forgot to subscribe to the project! :(

Ah, totally forgot! Thanks @Aklapper

This is now implemented in master, REL1_35 and REL1_39 😊

This commit breaks OAuth on MW 1.35
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/OAuth/+/839473/2/src/Backend/MWOAuthDataStore.php#130

Allright, I'll close GitHub issues as soon as we are ready to deploy

I'm good either way. @RhinosF1 whats your take on this. GitHub or Phabricator?

Agreed, Phab should (will be?) be main, but there are numerous people using github that don't know/want to use phabricator.
Maybe explicitly stating that phab should be used for reports (while leaving github issues open) could be a compromise?

Many thanks :)

Sounds good!

We could do that, but is it really necessary?

I hadn't found a way to create img and a elements without using Html::rawElement.
But I think as they don't contain user submitted content they should be safe.

CI fails due to one test checking if wiki.png is output, if no logo ist set. But it seems that the default logo name has changed to change-your-logo.svg in recent versions?

Possible performance issues

• Unless I miss something, PageHooks::onBeforePageDisplay() appears to always trigger a query like: select pp_propname, pp_value from page_props where pp_page=XXX anytime I display the main page, even though I have memcached enabled at my dev wiki. Always running a DB query on a pageview looks like a bad pattern. Is there any reason to not implement a caching mechanism?

Thanks for those insights @Urbanecm!
This sounds like unintended behavior, I’ll address this shortly.
Some aspects of the extension may be in need of updating, as world wide scalability wasn’t one of my concerns when writing the code.

Maybe I can add some info as the developer of this extension. I've forked the code around summer 2019 and have since rewritten it completely and deployed it on personal wikis.

Ah sorry, I missed that!
Message keys should be fixed now :)

In T284544#7154319, @abi_ wrote:

@Octfx - I still see messages using _. Can we stick to using - everywhere? Eg: embedvideo_video_short_desc, embedvideo_audio_long_desc, embedvideo_video_long_desc etc

In T284544#7151241, @abi_ wrote:

In T284544#7149935, @Octfx wrote:

Sure!
I've updated the current develop branch (and changed the source branch to develop also)

1. Sorry, I did not notice this earlier. but can we use hyphen's (-) instead of underscsore (_) for all message keys, just to be consistent? embedvideo_audio_short_desc --> `embedvideo-audio-short-desc
2. Can you update the description here to mention that this is a fork?

Sure!
I've updated the current develop branch (and changed the source branch to develop also)

This prevents edits using VE von MW Docker 1.35

This also happens, when using OAuth.
I've created a patch with the lines mentioned in patch.txt

Patch at https://gerrit.wikimedia.org/r/636623

Update: The 'patch' had an error on file pages.

In T265355#6545821, @Ammarpad wrote:

Both Timeless and Vector do not set the tag but they do generate the same trace as posted

How do they generate the trace?, give clear steps to reproduce

In T265355#6540652, @Ammarpad wrote:

I'm seeing a very weird bug with MW 1.35 and the Citizen Skin (uses mustache).
Using the Timeless with ?useskin=timeless the robot tag disappears (correct behaviour).
...I've narrowed it down to line 1019 in Article.php.

If it's not happening in 'Timeless', then how are you sure the issue is not from the skin where you're seeing it?. It seems strange also to be skin specific.

You should try another skin, Vector or Monobook to see. And you should also check what's the value of $wgDefaultRobotPolicy in your LocalSettings.php as well as other related variables. It'd be good to also check for NOINDEX magic word usages there.