Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
What about having enabled functionalities by default and options for disabling them.
Ex.
Demo Store:
Disable Jirafe eCommerce analytics
No demo Store:
Disable
- checkout for anonymous users.
- Custom "admin menu" designed for store owners.
- demo content #1776572: Provide ability to install with no demo content
- Jirafe eCommerce analytics
Comment | File | Size | Author |
---|---|---|---|
#3 | 1854060-kickstart-install-1.png | 311.71 KB | joshmiller |
#3 | 1854060-kickstart-install-2.png | 73.72 KB | joshmiller |
#3 | 1854060-kickstart-install-3.png | 306.73 KB | joshmiller |
Comments
Comment #1
bojanz CreditAttribution: bojanz commentedYes, I think we should at least enable some items by default (the custom admin menu one, for instance).
This needs to be discussed further.
Comment #2
joshmillerI actually like the idea of disabling Jirafe analytics for both the demo and non-demo installations. As for the rest, I'm not even sure we can toggle the admin menu on and off. For example, it would be really nice to have that only enabled by user role :D
Josh
Comment #3
joshmillerExpanding on this a bit...
During the installation, it would be nice if we had "Functionality" step prior to installing any modules.
Sensible defaults (but we ask the user about the following):
Also, the admin password should be switched to the more secure option by default.
The options could live in the above area, but at that point some of the modules have already been enabled that we're giving them the option to turn off...
Josh
Comment #4
Damien Tournoud CreditAttribution: Damien Tournoud commentedOn the contrary, I believe we already ask too many questions during the installation process. "Ask less questions upfront, give more options later" is a way better strategy.
Comment #5
marktheshark CreditAttribution: marktheshark commentedSome defaults I would personally find useful:
Thank you
Comment #6
bojanz CreditAttribution: bojanz commentedThis is already done by the Title module, it always has been (unless there's a bug preventing it from working in some cases).
This is fixed in Kickstart -dev.
Never. Variations inside Kickstart are always only managed from their display node, never from other nodes.
That would make sense. We try, but I guess it might need a bit more effort.
Comment #7
marktheshark CreditAttribution: marktheshark commentedTitles for variation types and display node content types were not created automatically in my case.
I don't understand what you mean by "Variations inside Kickstart are always only managed from their display node, never from other nodes."
Do you mean you don't support (by default) separate variation creation from display node creation? Could you elaborate? Thanks
Comment #8
bojanz CreditAttribution: bojanz commentedOkay, that's a bug, we're tracking it down.
That is correct.
In any case, this discussion is offtopic for this issue.
Comment #9
rickmanelius CreditAttribution: rickmanelius commentedI would also vote to have a more secure password assigned by default. After all, it serves as a good education point that one of the PCI compliance requirements is to have secure passwords enabled at all stages of the card data environment. I hate to think how many live sites might still use the default password...
Comment #10
bojanz CreditAttribution: bojanz at Centarro commentedKickstart is done.