History: Save current configuration as a profile

View page

Source of version: 12 (current)

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.

^ New in Tiki 12: [http://doc.tiki.org/Export+Profiles|Unlike the earlier tools to export as profiles, the command line tools cover the entire workflow of profile creation and perform better reference tracking between objects, allowing to create profiles that are more complete out of the box.]

New in Tiki 9.1: [https://dev.tiki.org/blogpost22-The-module-ificaton-of-Tiki-themes-easy-module-export-via-profiles-in-Tiki-9-1|Profiles can now export modules] ^ 

See also the documentation: ((doc: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 ((doc: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 ((doc:System logs)) to replay their steps and copy-paste the variable names.
^



Related: ((Profile Rollback))

Latest Changes

...more

Like almost all *.tiki.org sites, you can log in with your login from https://tiki.org (register over there)

Search

Most Popular Tags

admin agenda alias antibot antibot captcha app archive articles banning batch blogs calculations calendars cart categories cluster codemirror comments computation contact us datachannel debug debug console dropdown with other error messages features file galleries forums geo geocms geolocation group homepages group watches header i18n images item link items list jquery languages location map maps maths menu menupage multilingual ol3 ol5 openlayers paypal plugin plugin alias plugin datachannel plugin fade plugin tabs plugin trackerlist pretty trackers print project management r r project realnames rss static static text statistics stats structures syntax highlighter tablesorter template trackers user watches visualization watches webservice wiki wiki argument variables wiki structures

History: Save current configuration as a profile

Source of version: 12 (current)

Menu

Current Profiles

Latest Changes

Search

Most Popular Tags

About Tiki

Support

Community

Documentation

Development

Legal

Tiki Project Sites

Networks

History: Save current configuration as a profile

Source of version: 12 (current)

Menu

Current Profiles

Latest Changes

Search

Most Popular Tags

Tiki Newsletter

About Tiki

Support

Community

Documentation

Development

Legal

Tiki Project Sites

Networks