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

Comments

Yes, I think we should at least enable some items by default (the custom admin menu one, for instance).
This needs to be discussed further.

I 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

Title:Installation Disable options for Kickstart "Features" enabled by defaultSensible defaults for Kickstart 2 Installation
Component:Code» User interface
StatusFileSize
new306.73 KB
new73.72 KB
new311.71 KB

Expanding on this a bit...

1854060-kickstart-install-1.png

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):

[x] Demo
    [x] Custom Admin Menu
    [x] Shipping w/ Flat Rate
    [x] HTML Emails
    [ ] Jirafe Analytics
    [ ] Commerce Payleap
    [ ] Zoom & Gallery mode for products.
    [ ] OAuth
[ ] Non Demo
    [x] Custom Admin Menu
    [x] Shipping w/ Flat Rate
    [x] HTML Emails
    [x] Allow checkout for anonymous users.
    [x] Commerce Backoffice
    [x] Shiny Admin Theme
    [x] Omega Starter Theme (if unchecked, defaults to Bartik)
    [ ] Jirafe Analytics
    [ ] Commerce Payleap
    [ ] OAuth
    [ ] Additional blocks for featuring specific content.
    [ ] Frontpage slideshow.
    [ ] Custom admin menu designed for store owners.
    [ ] Blog functionality
    [ ] Social links for sharing products via social networks.
    [ ] Zoom & Gallery mode for products.

1854060-kickstart-install-2.png

Also, the admin password should be switched to the more secure option by default.

1854060-kickstart-install-3.png

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

On 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.

Some defaults I would personally find useful:

  • Titles replaced by title fields by default
  • As discussed in another thread, unlimited default value for product reference cardinality in a display content type
  • Inline entity form widget option to allow adding existing variations turned on by default (this was initially confusing to me)
  • Enabled display modes and field visibility as much as possible similar to the demo store

Thank you

Titles replaced by title fields by default

This is already done by the Title module, it always has been (unless there's a bug preventing it from working in some cases).

As discussed in another thread, unlimited default value for product reference cardinality in a display content type

This is fixed in Kickstart -dev.

Inline entity form widget option to allow adding existing variations turned on by default (this was initially confusing to me)

Never. Variations inside Kickstart are always only managed from their display node, never from other nodes.

Enabled display modes and field visibility as much as possible similar to the demo store

That would make sense. We try, but I guess it might need a bit more effort.

Titles 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

Titles for variation types and display node content types were not created automatically in my case.

Okay, that's a bug, we're tracking it down.

Do you mean you don't support (by default) separate variation creation from display node creation?

That is correct.

In any case, this discussion is offtopic for this issue.

I 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...