When people find out about profiles, one of the early things on their wish list is to make profiles of their existing Tiki installations so that they may clone them. The goal is to lower the time it takes to make a profile and thus, increase the probability that we'll have a lot of profiles.
See also the documentation:
Export Profiles
Opinion by marclaporte (January 2011)
- Profiles have matured nicely.
- Tiki customizations are progressively moving away from files (.css, .tpl, and .php) and more & more as preferences, managed via the web interface and distributable via profiles.
- Tiki7 will have a Theme Generator which stores all configurations as prefs.
Thus,
I think Tiki7 should have Tiki7 now has a basic profile exporter (tiki-admin.php?page=profiles -> export). Here is how I would see an export site to profile.
- Only export things that are different than the default (thus, we know it was an intentional change
- Show an interface to ignore certain prefs (ex.: domain name)
- Make it clear that it's only for prefs and not data (and especially not tracker definitions, which can have tricky dependencies
Opinion by marclaporte (February 2009)
While I can see that it can be useful, people are very surprised when I tell them it's not a high priority for me at this time. I will attempt to explain here. I am not saying no or never. I am saying I see many more things on the list ahead of that.
- I think the system is quite young and we don't really know how it's going to be used yet. I expect that we will find ways to use it that we hadn't anticipated. So automating that part of it seems premature. Will people use it more to distribute content? settings? etc. So let's find out more what people are using it for to know where further automation would be most useful.
- It would take coding time and I prefer to have that coding time to debug/improve what we already have.
- I see a risk where we could end up with a lot of junk. There would be hundreds of settings and we still can't get a feel of what is for what. We would definitely want a switch to say, only give me the settings that are different from the default. But then, we don't know which features are really there intentionally.
- As the profiles are currently, each line you add is intentional. And people can add explanations within the profile.
- I see the first phase of all this as building mini-profiles for very specific purposes, such as Custom_Contact_Form, Bug_Tracker and later on, more & more, we'll be combining these building blocks into larger use case profiles like Software_Project, Event_Management_System, etc. Since some of the profiles will actually deactivate things, I think it's better that every single line in a profile has a purpose.
- For example, if profile A intentionally removes the login module because it's adding the login feature in the top bar via Site Identity, we don't want a second profile to put back that login module, unless it's intentional (and it could be that we want that login box for admins to be able to use the Switch User feature which is not available in the top bar.
- Realistically, mostly power users will create profiles, and the current system is easy enough.
- As we have more & more examples, I expect forking will pages of similar profiles will be the way.
- Maybe people could also use System logs to replay their steps and copy-paste the variable names.
Related:
Profile Rollback