-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Various issues with new sampledata module and plugins #17415
Comments
Forgot also: |
Not exactly a bug. The code will prevent you from installing the same dataset twice "accidentally" as long as you don't refresh the page (to prevent accidental double clicks). As soon as you refresh the page, it lets you install it again. It will fail as soon as it gets a duplicate alias in a category when a model complains. I don't see a simple way yet to know in advance if a set is installed or not. And personally I don't think it's needed. It's not like something breaks if one installs the same set multiple times.
Not a bug but a feature. Imagine you have a sample data set for a specific extension.
Not a bug but a feature. It may be useless for the shipped sample data in your eyes, for someone else it may be useful. Anyway it is easy to remove since the data is all in its own categories. It's a bit of work to remove again, yes, but it's not like we're installing it by default.
Yes, that could be done. But not pick from the various installed languages, instead ship its own INI files.
I don't understand why it should be disabled. It works as expected also in multilingual context. From memory the added data is added with the currently active language tag (if not, that would be simple to do) and if translated strings are available, will install the translated sample data. It will not associated them thought, that would be much more complex.
It's a language string and thus easy to do. You want to do a PR for that?
The Control Panel is the first thing he will see after the installation is done. The module is present there for that reason. So he should see it.
No, but due to B/C we have to keep them. We will (hopefully) drop them from J4. It's the main reason for that new sample data feature so we don't have to keep those SQLs (we had various issues with them in the past).
In J3, the custom distros will work as they did before. For J4 I guess they need to be adjusted to sample data sets. |
Save the installed thing to the database ;) |
Why should we need to track in the database what sample data set(s) the user has installed? What does it matter if we're tracking it? |
And then what are you doing if the user removes the sample set and wants to install it again? Oops. That's what I meant with "simple". We would have to run queries to check which is installed and which is not. Each plugin will have to query for the data it inserts and return based on the result. But should it only check a few items or all? What if the install is incomplete for some reason? |
$params->set('sampledataset', 'XXX'); No extra database ;)
Give them a button to clear the value ;) else I guess we have just the chance to guess the installed sampledataset ;) |
It's still storing the data in the database. I'm questioning why we even need this type of tracking capability to begin with, not where to put it in the database.
Neither of those are good answers. To reverse the install is potentially destructive, especially if a user starts editing the generated content, or even worse has a site structure that might actually match the sample data set. Once installed, it doesn't matter what set(s) are installed or how many times you try to install them. |
I would not say it does not matter when we get the same alias multiple times for an article and a category. |
When one has installed Joomla as multilingual, the sample datas proposed (ini translated or not for the admin language in use) are NOT multilingual aware. All is tagged to ALL languages which is totally useless and confusing for someone starting a multilingual site. NOTE: BTW, |
The duplicate alias in the category looks like a bug in the category model. I would expect either the model or table to check that. Not sure why it doesn't. As for the added notice, I'm not that sure. First the model only shows on new installations, not on updated ones. Obviously, you usually don't want to install sampe data sets on a productive site, but there may reasons to do it. Not the testing or blog one but possible 3rd party ones could be useful (eg if you're trying a new extension). I still don't see the issue you have when in a multilingual site. Installing a sample data set on such a site is perfectly fine. Yes, it doesn't tag the active language. If you want, we can change it so it installs in the active language instead of "All", this would actually allow to install it multiple times (assuming you switch language between and the set is translated). Regarding the items tagged as en-GB, I actually just copied the existing set. There are other issues like content referring to no-longer existing templates and such things. Issues like that should be much easier to solve now. |
We can change the message to use "Do not install Core distributed Sample Data etc."
Indeed, but if the category part was doing its job correctly, the blog sample data would behave like it does for testing sample data, i.e. throwing an error at first try to install again. In
Therefore using |
Don't like it. How would you tell a core sample set apart from a 3rd party? And does that distinguishment even make sense?
I'm not sure. When I try to create a category in the backend with an existing alias, it fails with the expected error without creating the category, but in the case of the sample data it is created. The code used is in both cases the save method of the category model. At least that's what I think. Something must be different 😄 |
We just have to modify the title/description in the plugins, for example |
Don't see the reason for it. But if you want to propose a PR, go ahead. |
Will make a proposal. |
See #17456 |
Is this still an open issue or has it been solved elsewhere? |
This new feature has just been merged. See #7680
My tests show multiple issues.
Exemple for categories:
The testing sample data can't be installed twice as we immediately get an error
Step 1 Failed: Another Tag has the same alias (remember it may be a trashed item).
But we should get the alert even before it tries to install imho.
Another bug: it lets install another sample data after installing the first one. While Blog has been installed, one can also install the Testing sampledata. Imagine other plugins created and the mess it would create if any of the items has same name and alias in a similar hierarchy.
When a site has been created as multilingual at installation time (Setting is in Installation : No sample data, and later one after installing languages, install localised content), it still lets install sampledata from the module, all data set to ALL languages from the ini of the language used in admin at that time.
Although it does not break anything, it is totally useless on a multingual site and all data added has to be deleted, which is a real pain specially concerning Testing sample data.
I imagine a possible further improvement would be to create a specific multilingual sample data plugin which would pick the inis from various installed languages and create a more complex multilingual test site, but, in the mean while I suggest to NOT be able to install ini-based sample datas when the language filter is enabled with a specific Alert.
Improvements: The Alert displayed before installing the ini-based sample data should be more precise, i.e. stating that it is the data in the administrator language in use which is going to be installed and, if not present, default to en-GB.
The text was updated successfully, but these errors were encountered: