very very good idea

Tested.
A bit confused when installing branch as I did not know what to choose. Chose no sample data as if I was creating a basic multilang site.
Used the module link to install Testing sample data. All went well. Alias for Home was changed to home-1.
And there I did what I should not have done...:
I clicked again on the module link and it is still running today

Maybe should be considered :
1. Prevent installing another sample data if one has been installed (or the site has already some data. Imagine the mess if one kills his site this way...)
2. Add somewhere a Delete all data except the basic usual home page. This would let install a new data if desired.
3. Make all this fully safe to avoid messing with the site: Double Warnings, etc.

I clicked again on the module link and it is still running today

Yeah, I noticed that already soemtime ago. I need to fix that JavaScript there so it properly terminates and doesn't try to load the next step

Alias for Home was changed to home-1.

I was thinking about best approach with the home. Currently I create a new "main menu" and set the the existing "home" to a regular menuitem and create a new home from sampledata. This is something that could be improved I guess.

Prevent installing another sample data if one has been installed (or the site has already some data. Imagine the mess if one kills his site this way...)

I had that thought as well, but haven't figured out a sane way to do it. Also I could see that an extension could potentially provide its own sampledata set which can be installed with this.
I was also thinking about assigning all sampledata content to the currently active language, which then actually would allow to install the sampledata twice if you change the language. Just some idea for future

Add somewhere a Delete all data except the basic usual home page. This would let install a new data if desired.

Here it gets very tricky. Currently I store the inserted IDs in the session so I can use it later when I need to link eg an article to a menu item. After you close the browser, Joomla doesn't know anymore which content comes from the sampledata. Thus uninstalling it is not possible easily.

Make all this fully safe to avoid messing with the site: Double Warnings, etc.

Any ideas on implementation?

Any ideas on implementation?

Sorry, none. I see how useful it can be for a 3rd party extension once the extension is installed, but I see also all the possible failures.
Making it easy for custom full Joomla distribs to provide sample datas through an ini file looks promessing "at Joomla install time", but when already in administrator, it looks very dangerous.

it looks very dangerous.

It isn't really dangerous as it doesn't delete anything. It just adds data and modules. The only thing that is changed is the default "home" menuitem. Which is simple to switch back and we could also remove that from the sampledata if we want.
All modules can be disabled again easy.
All content is also added to own categories, so it's simple to filter for them and get rid again.

couple notes before I forget

use SampledataApplyStepXXX could have unexpected effect when there enabled a couple plugins that has the same method or I wrong?
Beacuse this, maybe better use <PluginName>ApplyStep($step), so it wil be adressed exactly to the <PluginName> and plugin internaly call which step is required ... means each plugin has "one enter point". (of course it not solwe the problem if another plugin has same method, but more safe, from my point of view)

And maybe we do not need $data->steps = 7; at all, we can just look on the request result, something like inprogress/done/fail

Currently I store the inserted IDs in the session so I can use it later when I need to link eg an article to a menu item

maybe can save this ids as parameters in related plugin, somehowe ... then it solwe reinstall problem, if user click install again we show warning, something: All previous data will be removed! you sure?

will try test this evening,
and hope I will find a time to help with JavaScript

I like the idea - the only problem is when someone installs one set of sample data on top of another set or even worse on top of their own content.

If you want to do it post-install like this then I would suggest the only way to do it properly is to remove all existing content before installing the sample content - obviously with plenty of warnings

use SampledataApplyStepXXX could have unexpected effect when there enabled a couple plugins that has the same method or I wrong?

I made this intential this way. So multiple plugins could run on the same step if wanted. Again thinking about 3rd party plugins which "hook" into eg the testing sampledata.
I haven't tested it specifially yet but in theory it should be possible to have a weblinks plugin which adds its own sampledata on the first step of the testing sampledata.
In the current plugins, I have a check included which returns empty if the request is not meant for this plugin.
I think it's also more in line with how plugins should work. The caller should not care how many plugins actually do something with the request.

Beacuse this, maybe better use ApplyStep($step), so it wil be adressed exactly to the and plugin internaly call which step is required ... means each plugin has "one enter point". (of course it not solwe the problem if another plugin has same method, but more safe, from my point of view)

The requests go through com_ajax. So using ApplyStep($step) will not work anyway. I would have to request the step from JInput and dispatch afterwards. In the end it would just add more duplicated code to the plugin I think.

And maybe we do not need $data->steps = 7; at all, we can just look on the request result, something like inprogress/done/fail

I need that mainly for the progress bar, so I know how big steps to draw. The other things could indeed be done without having that step property.

maybe can save this ids as parameters in related plugin, somehowe ... then it solwe reinstall problem, if user click install again we show warning, something: All previous data will be removed! you sure?

That would be a (quite hacky) idea. You would have to make sure they don't get overwritten when one saves the plugin. And it would need code again to delete the items using the models/tables. I wouldn't want to use direct queries there so we don't have to deal with nested sets, asset tracking and the like.
I'm not sure if it's worth the effort. Currently there is no way to delete the sampledata either

and hope I will find a time to help with JavaScript

That would be awesome. It's definitively not my strongest area. I was glad it actually worked

I like the idea - the only problem is when someone installs one set of sample data on top of another set or even worse on top of their own content.

Usually, installing two sets will fail due to already existing alias. I can solve that by automatically generate a new alias till it sticks, but I haven't seen the need yet.
But then, I don't see it as a big issue. Worst case would be someone presses the button on an existing site. This will generate and publish about six modules which will be visible on frontpage instantely. And it will change the home menuitem.
As said, the modules are easy to disable again. The home menu is the one which probably has most impact and we could change the sampledata so it doesn't change the home. If this is seen as an issue. Would make the code actually simpler

If you want to do it post-install like this then I would suggest the only way to do it properly is to remove all existing content before installing the sample content - obviously with plenty of warnings

I would never remove existing content. Even after 15 confirmation boxes I'm sure some users would accidentally delete the content. YCFS and I don't want to confirm that

So multiple plugins could run on the same step if wanted. Again thinking about 3rd party plugins which "hook" into eg the testing sampledata.

Sorry, then seems I wrong understand this part of the idea.

I thought that each extension (component) can have separated plugin, that can be installed separately, and each this plugin can provide own data collection (sorry for my English )

and <PluginName>ApplyStep still allow to "hook", even with biger precision ,
example we have next plugins:

• BlogData add:
  • Menus
  • Content
  • Categories
• BroshurData add:
  • Menus
  • Content
• TestinData add:
  • Menu
  • Content data
  • Category
  • .... all other core component
• SomeExtension2Data
  • Add data only for this extension
• ExtensionToExtendBlogData
  • Add data only for BlogData

So you can install BroshurData and then add SomeExtension2Data.
Or
If you run BlogData and ExtensionToExtendBlogData will "hook" in to BlogDataApplyStep() and add adittional data for the Blog

That would be a (quite hacky) idea. You would have to make sure they don't get overwritten when one saves the plugin.

true, but each plugin can have hidden fields that keep the list of ids:
field step1ids: 1,2,3....n
field step2ids: 1,2,3.....n
....

so if you need get access to these values you just do $this->params->get('step2ids'),
also this will help esianly to check which Data alredy installed and show the proper message if user want to insatll some incompatible SampleData ... in theory

yes, it still hacky ... but also I think that it not so bad

Sorry, then seems I wrong understand this part of the idea.
I thought that each extension (component) can have separated plugin, that can be installed separately, and each this plugin can provide own data collection (sorry for my English )

You didn't understand wrong. It's both variants which should work (in theory).
I think renaming the methods is a good idea and makes it a bit simpler as we can get rid of those lines in each method: https://github.com/Bakual/joomla-cms/blob/ModSampleData/plugins/sampledata/testing/testing.php#L83-L86
You're right that it still allows the same flexibility.

true, but each plugin can have hidden fields that keep the list of ids:
field step1ids : 1,2,3....n
field step2ids : 1,2,3.....n
....
so if you need get access to these values you just do $this->params->get('step2ids') ,
also this will help esianly to check which Data alredy installed and show the proper message if user want to insatll some incompatible SampleData ... in theory

I think I like that idea.

I presume these plugins are going to be core-supported (we can package them up into the full install packs) - but we once people are done with them then they need to be uninstallable and not reappearing on updates?

once people are done with them then they need to be uninstallable and not reappearing on updates?

Good point.
If we handle it like weblinks, but ship it with new installs then we need to figure out how we want to handle the installation SQL that installs/enables the module and plugins. I guess it gets interesting if the extensions are in the SQL but those using the Git repo to install the CMS are missing the files.

We could of course make them installable as a package without it being included in core, but that kind of is counterproductive for the sampledata. Doesn't make sense I guess.

Not sure what the best approach is here and how it can be handled.

I'm hoping this module will make it in the final 3.5 release. This will really (like really) come in handy for third party vendors. The question that I hear over and over again from my customers is if they can install sample data on an existing Joomla site with data and for me this will be a relief to know now it's possible. Kudos Bakual :)

It will certainly not be in 3.5.
It may go into 3.6, but then there should be webservices available with 3.6 which means the whole thing could be written using those webservices. Thus it's unlikely that the module will go in as it is now. Most likely it will be rewritten to use the webservices we are supposed to have by then

@Bakual i din't know about this PR until you pointed. Thanks.
Is this waiting for 3.7 webservices?

Kind of, yes.

ok then. will wait.

I have tested this item ? unsuccessfully on 9e2d6ac

Applied patch and discovered module and 4 plugins. Activated plugins and added a module in cPanel position.

Deactivating one of the plugins changed the possible sample data to install.
Choosing 'Testing sampledata' gave a modal window with untranslated text MOD_SAMPLEDATA_CONFIRM_TASK.

Could not revered the patch
Applying OK resulted in 'Step 1 Failed: Another Tag has the same alias (remember it may be a trashed item).'

Is this still scheduled for 3.7.0?

I haven't heard about webservices for some time. Maybe @rdeutz and @chrisdavenport know the current state and what should be done here.

I have now updated this PR with latest staging and it should work again. It needs still a lot of work but since Webservices doesn't seem to gain much traction lately I thought it may be worth to revisit this approach.

Install "Blog Sampledata" got:

after "OK":

now installed next 3 Sampledata (always warning like in first Screenshot) which gave thie Result:

Test on:

Joomla! 3.7.0-beta1-nightly
macOS Sierra, 10.12.2
Firefox 50.1.0
PHP 7.0.4
MySQLi 5.5.53-0

The testing one is the only one which currently installs something, the others don't do anything. So that part is expected.
Looks like the testing sampledata installed fine. If you also got all those articles, modules and stuff in your site, then it went successful.

I know there are still missing language strings (like the start message). That still needs some work as well.

Since this is a RFC (Request for Comment) type of PR, I'd also be interested in what you think as a user.

i really like this approach

I like this kind of Opportunities and Flexibility.

I have tested this item ✅ successfully on 136ca2c

It is a good direction but (my 2 cents, this is only an idea):

• why not move it to Extensions: Install -> new tab: Install sample data.
• Each sample data can be installed/used only once in the same time. There could be installed a few different samples data if they do not have any collisions.
  • ex. add method to plugin "isCollissionExists()"
• every installed sample row (in databse) should be saved in history table to help uninstall process.
  ex sample_history (sample_data_name, table_name, record_id, record_unique_column_value)
• joomla will have a few core samples data not installed by default.
• after admin click on "Download core sample data plugins", then plugins will be installed, this will be only a shortcut to install from URL.
• custom samples can be install as a regular plugin.
• admin can click on "Install sample data" (or Enable) button on every plugin in plugin list
• the plugin will check if can be installed and install own data
• after that "Install sample data" button will be replaced by "Uninstall sample data" or (Disable) instead;
• 3rd party extension may have own samples data plugins.
• Each "plugin sample data" can be uninstalled without removing sample data from database but history stay.

why not move it to Extensions: Install -> new tab: Install sample data.

I think that could be considered. When I initially wrote this, I don't think the installer was already built with plugins. On the other hand, the cPanel is the first page you see after installation and having the sampledata installation prominent makes sense to me. It's also easy to disable.

Each sample data can be installed/used only once in the same time.

There is currently some JavaScript which prevents "doublecklicking" it. But after a page reload you could press it again. It could be tricky to really detect if a sampledata is already applied. Imho we better design the data so it could be installed multiple times.

every installed sample row (in databse) should be saved in history table to help uninstall process.

Imho, that's a big overhead you will get here, as you will have to store the data into an own table. And you're still not sure if the sample data hasn't been adjusted to a productive value.
There is also currently no way to uninstall the sample data after installation. So I didn't try to include it.

joomla will have a few core samples data not installed by default.
after admin click on "Download core sample data plugins", then plugins will be installed, this will be only a shortcut to install from URL.

Imho, that's to much overhead as well. The plugins are really small ones and will not hurt when installed by default.

custom samples can be install as a regular plugin.
3rd party extension may have own samples data plugins.

Already possible. Extensions could either hook into the existing sampledata plugins or have their own set of data.

admin can click on "Install sample data" (or Enable) button on every plugin in plugin list
the plugin will check if can be installed and install own data

Imho, that would be quite unexpected. When I install a plugin, I don't expect it to alter my data right away. Also, you wouldn't have any progress and it could easily time out since it's not using AJAX during plugin installation.

Thanks for details.
I can admit you are right in most points but I would like to have an option like "Erase core database tables before install sample data" but it is probably too risky.

Please consider Extensions: Install tab then the module can be as shortcut if needed.

"Erase core database tables before install sample data" but it is probably too risky.

I agree that is to risky. ?

Please consider Extensions: Install tab then the module can be as shortcut if needed.

Imho, it is the wrong place as we are not installing any extension here. We insert/create content. But it could be done. Technically it's an AJAX call to com_ajax which itself triggers some plugin events. This call can be done from anywhere.

If you go this way:
* Extension: Sample Data
* administrator/index.php?option=com_installer&view=sampledata
then in the future you won't be limited to only ajax calls.

I'm just not accustomed to interaction between the module and the plugin to perform some action.

I only send idea, I do not think about it too much, I know that adding advice is easier than make it.

So, if you don't see benefits
then please resolve current file conflicts and I will test it as is now.

Would it be possible to adopt the same architecture like installation/sql/mysql folder whereby if a third party vendor places their sql file within the plugin, it will be added in the list of installable sample data?

Which PR should I download to test this?

then in the future you won't be limited to only ajax calls.

It would be the exact same code in that view, just with the overhead of a full view instead of just a simple module. So it would as well be limited to AJAX calls. But then I don't see why that could be an issue. Within the plugin the extension developer can do whatever he wants. Tehre is no restricting factor to my knowledge.

I'll try and see if I find some time to resolve the conflicts so it works again ?

Would it be possible to adopt the same architecture like installation/sql/mysql folder whereby if a third party vendor places their sql file within the plugin, it will be added in the list of installable sample data?

The main reason for this PR is to move away from plain SQL files for sample data. So no, it doesn't support those ?
3rd party developers can write an own plugin which either offers their own sample data set (which shows up in that list) or hooks into an existing one.

Which PR should I download to test this?

This one :)

PR is rebased and conflicts solved.

Blog sampledata should now work as well.

if we get two successfully tests for this I will merge it into 3.7 as an alternative for loading sampledata

Yesterday I have tested it on mysql and seems to be ok. Today I will complete test on other dbs.

@rdeutz will test today.

I have tested on installed Joomla and patched by your PR.
Next discovered module and plugins and enable them.
Next install blog sample and found one untranslated menu item

On postgresql joomla patched after install do not add automatically module and plugins. I have to discover it.

When I try to install testing sample I got

On postgresql

Some Lang.-Strings missing, Error-Message at bottom:

Author-Menu

Test on

Joomla! 3.7.0-beta3
macOS Sierra, 10.12.3
Firefox 51.0.1

MAMP 4.1.1

• PHP 7.0.15
• MySQLi 5.6.35

Thanks for the tests. Very appreciated!

On postgresql joomla patched after install do not add automatically module and plugins. I have to discover it.

The PR is missing the changes in the install SQL files for PostgreSQL and MSSQL. I think I can do them today. It's also missing all update SQL files. I can add them as well. I think I will add the module without an active instance and the plugins disabled for updates. They don't make much sense on an existing site.

I need to check the other error you got about the metakey. I guess I need to pass a metakey property then explicitely.

The missing language key is likely an easy fix as well.

@franz-wohlkoenig Brochure and Default Sampledata aren't done yet. So that is expected.
The invalid response is because of an already existing menutype, namely the "main menu" one which is already created by the blog sampledata. I saw that already yesterday but don't know yet why it doesn't show a regular error message. Somehow the AJAX response gets messed up in that specific case.

@rdeutz Do you want to just merge the testing and blog sampledata plugins? Then I can try to fix them and remove the other two which aren't done yet to get this PR ready. The other sampledata sets could be added later.

If you want to see more errors on mysql you can change libraries/joomla/databse/driver/mysqli.php
Line 186 to more strict which we are on J4:

		// Set sql_mode to non_strict mode
		mysqli_query($this->connection, "SET @@SESSION.sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';");

I have tested this item ✅ successfully on 75d08d4

Test is successful cause of Statement

@Bakual Issue on Author-Menu is solved by installing testing and blog sampledata plugins?

I removed the non-working plugins for now. So you now only get the testing and blog sampledata sets.
Both should work, I fixed some issues with the blog one, so the untranslated string should be gone.
I also tried a bit with strict mode and fixed some of the errors at least.
However in strict mode it's hard to say if the error comes from the plugin or elsewhere, there are a lot of issues here ?

I also added the installation SQL files for PostgreSQL and MSSQL. Please test those.
The update ones are still missing.

No Test on MySQL?

No Test on MySQL?

Sure, test on MySQL as well ?
I just mentioned the other two dababases because they were missing the installation files before.

Step 6 Failed (Multilingual-Site):

Test on

Joomla! 3.7.0-beta3
macOS Sierra, 10.12.3
Firefox 51.0.1

MAMP 4.1.1

• PHP 7.0.15
• MySQLi 5.6.35

woow... if this merged into 3.7.0, it means a lot of work for tts, who have already a lot to do to cope with all the new stuff since 3.6.5
i suggest to wait for 4.0.

also, as this is an older pr, there are module positions which do not exist anymore (atomic) and wrong dates and versions. will test tomorrow to evaluate fully.

We aren't merging this for 3.7 - it's past alpha and this is definitely a feature.

@franz-wohlkoenig It should work when you only install one set or both only once. When you install them multiple times, it may clash because some alias are duplicated, in that case the "home" menu item alias.

woow... if this merged into 3.7.0, it means a lot of work for tts, who have already a lot to do to cope with all the new stuff since 3.6.5

I think this is quite optional for translation. Like the current sampledata which isn't translated to my knowledge (except for language specific installation packs).

also, as this is an older pr, there are module positions which do not exist anymore (atomic) and wrong dates and versions. will test tomorrow to evaluate fully.

Yeah I noticed that as well, but imho they are still present in the current SQL sampledata. When I did the PR I just copied the text from the SQL file. The sampledata sets need to be worked on for sure.
I'm not sure if it should be done before 4.0 thought. Looks like a bit of wasted time to me. It will also be easier to rework the sample data with this approach than changing them directly in the SQL files.

@Bakual i installed both only once, for each test new installation. So i thought its about multilingual-site as reason of alias-clash.

We could name the "home" menuitems for the sample data sets differently. Like "Blog Home" and "Testing Home". Then the clashing would be gone.

Renamed Home menuitems to something more unqiue.

On postgresql for testing sample I got:

"ERROR:  null value in column "extrainfo" violates not-null constraintDETAIL:  Failing row contains (1, Joomla, Administrator, banner@example.com, null, 1, 0, 1970-01-01 00:00:00, null, 0, , -1, -1, -1)."

We should allow NULL values :-p
I'll have a look tomorrow.

I have tested on mysql, postgresql and sqlsrv with success.

About menu:

• testing sample has duplicated menu item title: Parks, Parks
• blog sample has menu item Blog Home and About and they point to the same article but there exsts another article "About your home page".

The duplicate "Parks" is actually correct because it is like this in the current testing sampleset. See
https://github.com/joomla/joomla-cms/blob/staging/installation/sql/mysql/sample_testing.sql#L468
https://github.com/joomla/joomla-cms/blob/staging/installation/sql/mysql/sample_testing.sql#L483

The "Blog Home" and "About" only look like the same page if you're not logged in. The first one is a category - blog view, the second one a single article view. If you're logged in, you will see more articles in the "Blog Home" one.

For Blog Sample - OK, after I logged in then I see the second article.

For Testing Sample there is still (Parks, Parks) - but I see now the same on Backend, so it may be OK.
Before (old testing sample before PR):

After (new testing sample):

Front end:
Sample Sites -> http://[..]./index.php/your-profile
Parks -> http://[...]/index.php/parks-home
Parks -> http://[...]/index.php/welcome

My system:
php 7.0
mysql 5.7

I think too much harping.
The new sample just a little bit different.

I have tested this item ✅ successfully on b6093eb

Ah I now got what you mean with Parks Parks. I can look into that, should be a simple fix. But not today anymore ?

Fixed the Parks Parks thing and another one in the same menu.

Now menu is OK

When you change text: "Something went wrong! Please reboot the Windows and try again!"
to something more elegant then I will mark it as test success.

Any suggestions for text? ?
Maybe "Something went wrong! Please close and reopen the browser and try again!"? Makes at least more sense to me. But maybe "Something went wrong! Please contact the site administrator!" is maybe more appropriate. I don't know ?

It could be the first one, but sometimes once IIRC I had to reinstall joomla to fix such error.

Changed the text ?

I have tested this item ✅ successfully on 2d7bf18

I have tested this item ✅ successfully on 2d7bf18

RTC

Quick note on this: We will not include it into 3.7, but in 3.8. It is too much work for the translation teams and we are behind a stage to include new features

As far as I'm concerned we're good with putting this into 3.8. No matter when it gets added, it's a lot of new language strings; there's no getting around that, and with us not merging any other major features for 3.8 this really should be the only translation effort requested for the release (and probably the last major work needed in general until we get to 4.0).

The SQL files just need some additional updates (part of it is merge conflicts, part of it the assets table note).

I'll try to update it during next week to get it ready.
The language strings itself need some work as well. I just copied them from the existing sample data, but in fact there is a lot of outdated information in it. It probably is easier to review them once they are language strings than within the SQL files.

@Bakual maybe better wait till we are in beta state for 3.7.4

I have to solve the conflicts and fix the issues Michael mentioned anyway.

It's a new feature so it will be 3.8 and not 3.7.4

On 1 Jul 2017 7:45 pm, "Thomas Hunziker" notifications@github.com wrote:

I have to solve the conflicts and fix the issues Michael mentioned anyway.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#7680 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8YPVGz3i0O1LvRCnU8nI_CJHTbRBks5sJpO-gaJpZM4FpTTt
.

This PR is updated with staging and I think I have fixed all issues that were raised.

Hey Thomas,

as much as I welcome this feature, as @csthomas commented in February this year, I'm also not convinced yet, that this should be done via a module and / or a module, that sits in the control panel. I would expect to find this in a new tab here: administrator/index.php?option=com_installer&view=database, too.

The module is currently visible for users of the manager group. Given that even a big warning sign, saying: "do not push this button (in production)" wouldn't prevent someone from doing so, maybe it should only be available to super users, who are the only ones to be allowed to install anything (if not set otherwise). You know, the "with great power comes great responsibility" kind of thought, even though we're "just creating content" here.

Moving it to the view / tab mentioned above could not only solve that rights issue, but allows for better usability and / or maintainability. Like, how long can that sample data list become and how can I visually differentiate between plugins from different extensions (think of a list view incl. filters / flags: by extension, applied state and so on)?

Speaking of demo / sample content and I'm happy to talk about this somewhere else, if this isn't the right place for it. I would highly recommend every demo content provided for core extensions to be set to "noindex", "nofollow". Hopefully this saves the "seo guy" some time to clean up or replace the content. This sort of stuff could go hand in hand with some post installation message and / or a demo backend module ;-) that explains the first / next steps.

Thank you for the work you have done so far.

My reason to put it in the cpanel is that this is the first page one sees after an installation. If you hide the sample data somewhere in the installer, those who would need it will maybe find it only when they don't need it anymore.
Also the module approach allows to disable the module easily if not needed.

But of course that is my subjective view ?

how can I visually differentiate between plugins from different extensions (think of a list view incl. filters / flags: by extension, applied state and so on)?

I've written this explicitely so you don't have that differentiation. For example any plugin can hook into "Testing Sample Data" and add its own data as well.

The module is currently visible for users of the manager group.

From memory, we only have a "Special" viewlevel. No viewlevel for Super Users only.

I would highly recommend every demo content provided for core extensions to be set to "noindex", "nofollow".

That should be simple to do and makes sense.

Thank you @Bakual.

My reason to put it in the cpanel is that this is the first page one sees after an installation. If you hide the sample data somewhere in the installer, those who would need it will maybe find it only when they don't need it anymore.

Imho, the problem doesn't really exist. I thought about the installation of the sample data as an optional / additional step of the overall installation process, where one still opts in to install them (or not) and would then get redirected to that mentioned view (active tab) as the last step.

That would leave everyone who wants sample data exactly where they need to be, without any distraction and also knowing where to find it later, without the need to re-/activate, re-/order or re-/assign a module to work with, or to rely on a post installation message alone.

I've written this explicitly so you don't have that differentiation. For example any plugin can hook into "Testing Sample Data" and add its own data as well.

If sample data can be installed / switched later, we can also think of this as a / the new way of how to pre-configure a distribution. From a developers perspective and without going too much into details here, personally I would want as much transparency as possible.

Allow me to throw in some general thoughts at this point, and excuse me, if some of this has already been mentioned / addressed: non-blocking failures, logs, security*

*Before I'll get to the ACL aspect, one or two words about security. Again, correct me if I'm wrong.
Either com_ajax and / or the plugins would need some form of identifying where and from who the request is coming from.

I haven't fully tested it, but by the looks of it, knowing the plugin and method, I could call each step directly from the frontend, right?
http://localhost/modsampledata/index.php?option=com_ajax&format=json&group=sampledata&method=SampledataApplyStep1&plugin=SampledataApplyStep1&type=testing

From memory, we only have a "Special" viewlevel. No viewlevel for Super Users only.

There is a Super User access / view level, but my point was that "until now" the page is set up by the Super User and he / she decides if / what / and when sample data will be installed. With that module, if set to anything but Super User, we would need to change that and introduce room for potential errors.

The module manager for example, is currently not accessible for users assigned to the manager group, who belong to the access / view level "special". They wouldn't be able to de-/activate ~ manage that module, unless we change the access / view level for the module manager, too.

Thank you again for your consideration.

If sample data can be installed / switched later, we can also think of this as a / the new way of how to pre-configure a distribution.

Yep, that was my thinking. And as an extension developer, I would love a way I can hook my extension into a "distro" set. So if someone is going to run the test sample data, there is also some test data for my own extension. With the current plugin approach, that was just the way it works since any plugin can listen to any event.

Either com_ajax and / or the plugins would need some form of identifying where and from who the request is coming from.

True, I think it's missing the tokens. There should be some ACL involved when the data is created since the models do check that to my knowledge (again from memory which may be wrong).

There is a Super User access / view level,

True enough. Would make sense to use that level instead.

OK So there is one question that arises. Are data sets ever going to modify the admin menu? Because now this is customisable for example for blog sites you might want to have a different admin menu. This would require these scripts to be run before we get into the administrator

I also still have a question about what we do once people are done with installing sample data when the plugins need to be uninstallable and not reappearing on Joomla Updates

So far the sample data sets never have touched the admin menu. Didn't made sense since anyway. But it may be a possible use in future for sure.
I'm not sure if it has to be run before you get into admin thought. Just add the new menu items and don't delete existing ones similar to what I do in frontend where I don't touch existing menus (except for the "Home").

I also still have a question about what we do once people are done with installing sample data when the plugins need to be uninstallable and not reappearing on Joomla Updates

Once the module is unpublished, the plugins will do nothing anymore since there is nothing triggering them. The module will not pop up again after an update.
So I think that should be fine.

What's the state here?

I've now fixed the asset issue you mentioned and I changed the access level so it's only visible to the super users.

I think I need to add the CSRF tokens to the module and plugins. If you merge it before I get to do that, I can do it also in a separate PR.
I'm not sure if we have to do any ACL checks in the plugins. The respective models should imho take care of that, but of course we could add some component.create checks as well into it.

@matrikular raised the question if it should live in a different place (eg installer) instead of a module in the cPanel. However I doubt I have the time to change that. So that would have to be done by someone else if you guys also think the cPanel is the wrong place.

I haven't done anything for people updating. Not sure what we should do there. Add the module/plugins to the #__extensions table but unpublished? The module certainly shouldn't show up for existing sites.

I haven't done anything for people updating. Not sure what we should do there. Add the module/plugins to the #__extensions table but unpublished?

That'd probably be a good idea. We shouldn't put an extension onto a site that isn't properly installed, so without that it'd be sitting in abyss and people hitting discover would stumble upon it that way.

Will add the update SQLs this evening so the plugins and module are installed but unpublished.

Added the update SQL files which will install the module and the two plugins as unpublished extensions.

Nice work @Bakual ? ?

versions and date, including copyright, need correcting

The only thing that needs to be manually corrected is version tags and dates in the new extension manifests. The version bump script will take care of version placeholders and copyright headers.

Tested and commented #17415

I've just read about this feature in the article about beta of 3.8 at the joomla.org and it looks like a nice addition. I've looked quickly at the code and I think that I missed something obvious - how do I build own sample data for the whole site with this approach?

Do I need to build the sample data plugin by hand?

At the moment I can prepare a QuickStart installation package with own sample data by exporting and adjusting SQL dump file in a matter of minutes. If option to install sample data will be removed from installation, with this approach I will need weeks? to create that kind of plugin for scratch.

It is a nice addition to install some sample data for a single extension after installation, but not for the whole site. In this case some kind of feature to import/export content would be great. I haven't looked closely at the whole code yet, so I'm sorry, but I must missed something obvious, how do I build own sample data for the whole site with this approach if installation of SQL dump will be removed from installation?

Do I need to build the sample data plugin by hand?

You need to write your own plugin if you want to have a different sample data set.
Now I'm not exactly sure what you want to do exactly. If you just want to adjust the text, you could copy the existing plugin and alter the strings in the INI files. If you need a different structure, then you indeed need to write new code.
However depending on your needs, the code can be much simpler than what I wrote for the core ones.
Your plugin needs the "onSampleDatagetOverview()" method (eg https://github.com/joomla/joomla-cms/blob/staging/plugins/sampledata/blog/blog.php#L62-L72). That method just has to return an object with the name, title, description, icon and the count of steps.
And then you need the respective amount of steps as functions like "onAjaxSampledataApplyStep1()".
If you want, you can do it all in one step and just apply your SQL commands directly there and be done.

For core, the intention was to get rid of those SQL files because we had to always do three sets of them for the various databases we support. Also there was always errors in them (eg wrong assets and the like). That's why I use the respective models and tables so i don't have to deal with the stuff Joomla can handle itself.

@Bakual, Thank you for your reply.

Now I'm not exactly sure what you want to do exactly.

What I want to do - I want to build a QuickStart package, this is an additional, optional installation type of Joomla! provided by most, if not by all template providers.

The name varies by different providers, for example Gavick call it a QuickStart package, RocketTheme call this a RocketLauncher ...

Basically, it is a modified, complete installation package of Joomla!, that contains files of third party extensions and own SQL sample data, that are used during installation.

After that kind of installation, client get's an exact copy of the demo site, that already has all used extensions, content and settings as in the demo site of the template.

Basic advantage of this type of installation was, that client didn't had to install everything by hand, and tries to recreate content of demo site, or guess what settings were used.

Of course this was intended only for new installs, because there was no offical way to import content in existing site.

Currently it was quite easy to build that kind of package, as you just needed to have a modified package with all additional files + own modified SQL sample data file.

Option to install sample data after installation is great (and I do understand that is a better way to handle that part of installation for the core) and it opens a new ways for developers, but if this possibility will disapear in 3.8, this may cause a lot of problems for the template providers.

I didn't have time to review the code yet but thanks for the tips!

Does decision to remove import of sample data during installation in 3.8 was alrady made? In beta I still see it in place? Once again thank you for your reply.

Does decision to remove import of sample data during installation in 3.8 was alrady made? In beta I still see it in place? Once again thank you for your reply.

It will stay in place through the rest of the 3.x releases. We are looking at removing the sample data SQL files for 4.0 though.

Even if those do go away, you'd still have a couple of options for using Joomla's native web installer to create a quick start package:

1. Modify the core joomla.sql file with your additional data
2. Core supports a localise.sql file which some language distributions use to create localized data at install, you could use that to your advantage to plug in your additional data

Another thing to keep in mind is with the plugin approach, you wouldn't have to build and distribute a customized Joomla distribution. It might take some extra steps for end users, but as a distributor/packager it may be easier to use the plugin approach and advise users to install your sample data plugin which creates the same end result as your fully packaged quick start (instead of having to synchronize the entire package with each release, your plugin has the instructions in it to install the extra extensions, load the data, etc.).

It will stay in place through the rest of the 3.x releases. We are looking at removing the sample data SQL files for 4.0 though.

Even if those do go away, you'd still have a couple of options for using Joomla's native web installer to create a quick start package:

Great to hear that! I was worried that 3.8 will bring some biger changes without any prior notice.
Also, it's nice to hear that the same/similar approach will still be an option, even in 4.0.

Yes, I see many possibilities and advantages here, so I'm happy to see such a feature available in the core. Overall process could be simplified for both sides and what is more important not limited only to the new installs.

Thanks guys for your replies and for the contribution!

Hi :3 Thanks everybody for your just amazing effort and results.

I just installed Joomla 3.8.0 by the cpanel softacolous script. The only choice I happen to receive as I login the admin panel, is "Blog sample data". I checked the plugins, and the blog sample plugin is the only one installed.

What could I do to try and set other sample data plugins ? I would love to install the testing one.

Sorry for bothering you here :3

The testing sample data is not distributed with Joomla - it is only for testing during the development process

Well, I probably misdefined. I talk about the "install all modules and menus" sample data set.
Thanks :3 Last question then I won't bother anymore in the wrong place :) Is there a way to find more sample plugins and install them?

There is the testing sampledata plugin which can be found here: https://github.com/joomla-extensions/testing-sample-data/releases

Other than that, there are no other plugins from core. But I'd expect more such plugins to come, especially from template provides as part of their bundles.

Thank you everybody for your very kind help :3