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