@dgrammatiko @richard67 cc

This will make it harder to install Blog sample data multiple times when having a multilanguage site, one time for each backend language. It will need to enable the plugin again each time.

Currently we can change language in backend and install blog sample data for each language, and when we later install another backend language, we can do that again for that language.

This will not be possible anymore in this way.

Ping @infograf768 .

This will not be possible anymore in this way.

Not impossible, just more steps :) you would need to republish the module and plugin each time.

Lets keep this in context. for 99.9% of the life of a REAL Joomla site, the Sample Data plugin/Module are not needed to be running on the site.

The sample data plugin is for developers in development mode, and for those testing Joomla.

This is not a flagship feature of Joomla that is used day in and day out by 100% of those using Joomla. Its used by a select few people for a select reason.

Whereas, the performance "issues" (the tiny bit of performance gained) is applicable to each and every live site site in real use.

Currently we can change language in backend and install blog sample data for each language

This is a flaw in the current architecture of the sampledata plugin/modules. The CMS has all the data (installed languages and content languages) to decide (or even ask the user) if the data should be installed in one or more languages. AFAIK there's already an open issue about sampledata: #32878

AFAIK there's already an open issue about sampledata: #32878

That issue doesn't cover the multilanguage aspect.

Regarding this PR here it's not on me to decide if it's ok or not, I just wanted to mention that aspect here so it is not forgotten.

I agree with @richard67
We absolutely need to be able to install multingual sample data and thereafter blog sample data for each content language.

We absolutely need to be able to install multingual sample data and thereafter blog sample data for each content language.

This PR doesn't stop you doing that at all.

It just means you need to REPUBLISH the module/plugin AFTER each use.

As I have stated before ad nauseum there is zero need to have the multilingual sample data plugin enabled if the site is not multilingual

We absolutely need to be able to install multingual sample data and thereafter blog sample data for each content language.

If the only way to do that is by doing it manually we should pack it here and start farming...

As I have stated before ad nauseum there is zero need to have the multilingual sample data plugin enabled if the site is not multilingual

tell me a check I can make to find this out. I have never used Joomla and multiple languages. Im white british, the education system only taught me one language (badly)

tell me a check I can make to find this out

Count the languages in __extensions select * where 'type' = 'language'and the content languages in __languages

It is very simple, once one has tested the feature at will, to start from scratch as was always done and then unpublish the module.

but, as usual, do whatever you like.

Nothing in that sentence makes any sense at all

then unpublish the module.

I bet 10-99% of Joomla admins will never unpublish this module manually ;-)

In Blog Sample Data we use this to check if we have multilanguage on:

https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Language/Multilanguage.php#L43

I bet 10-99% of Joomla admins will never unpublish this module manually ;-)

Anything less than 98% would be a surprise for me

@PhilETaylor see #20749

@brianteeman thanks - that's looks simple and that logic can be added to this PR... basically if there are more than 1 lang then we will not unpublish if you just installed the multilane sample data... simple. Keeps everyone happy.

It is simple but one person objects to it as they believe no one will know you can do it unless you shove it in front of their face until they get so annoyed with it they uninstall joomla

If I were (as I wanted to do) uninstalling (which means deleting the db rows and the module/plugin files from the hard disk) then I could understand... however all we are doing here is unpublishing here :) :

081da58 just pushed will only unpublish if the Multilane data is installed on a site with just ONE language

Please test.

The module itself should not be unpublished. Keep in mind that the module isn't exclusively used for core sample data. Each 3rd party extension can provide its own sample data as well. And I know for example DP Calendar does that.

I'm not a big fan of extensions who publish/unpublish themself. I would offer a button to directly unpublish the plugin instead. So it can be hidden with a single click.

We already have that button ;)

Disable the plugin automatically THEN
If there are no plugins to display the module is empty and as there is no point in having an empty module just hide the module. That way if an extension is installed later that has a sample data plugin it will still be displayed

Each 3rd party extension can provide its own sample data as well. And I know for example DP Calendar does that.

I bet you cannot name another 5 extensions that use sample data like this ;-) ;-) ;-)

I bet you cannot name another 5 extensions that use sample data like this ;-) ;-) ;-)

I can't name 5 but I can point you at https://github.com/dgrammatiko/sloth-pkg/tree/main/plg_sampledata which is way different from the core monstrosity plugins... ;)

LMAO - typical JS developer :) hahahahah

 defined('_JEXEC') || die('<html><head><script>location.href = location.origin</script></head></html>');

Each 3rd party extension can provide its own sample data as well. And I know for example DP Calendar does that.

I bet you cannot name another 5 extensions that use sample data like this ;-) ;-) ;-)

I dunno, but that was one of the initial ideas of using this approach. So instead that the extensions put their sample data hardcoded into their SQLs (like core did before), they can offer a plugin as well (like core does now).

Obviously, the module could return empty if no sample data plugin is active (don't know if it does that today already).

I would offer a button to directly unpublish the plugin instead. So it can be hidden with a single click.

We already have that button ;)

@brianteeman I meant for the plugins. I know that the modules all have such a button, that's where the idea came from ?

#20749 (comment)

As I see it, if merged, this feature would become a hidden secret which would only be eventually used by devs and bugsquad.

Well it certainly doesn't need to command prize position on the home page of the admin console does it? it gets used less times in a sites lifetime than the number of fingers on a hand...

Imho, it would be nice to be in that position if there are sample data available. Otherwise people don't see them.

But it would also nice to be able to unpublish the plugins directly from the module, as it is not very intuitive to know where they can be hidden. So a button either on each sample data set or on the module ("Manage Sample Data" for the lack of better wording) would be great.

It would also be nice if the module hides completely if no plugin is active.
Currently it shows like this:

I certainly wouldn't automatically unpublish anything.

I've created a simple PR to hide the module if no sample data plugin is published. See #33168

Button to go directly to the pluginmanager to disable plugins:
#33169