Moved to dev: install
old stuff below kept for archives
This is the central place for discussing the future of the Tiki setup process.
- RFEs and ideas in Mailinglists, fori etc. should be digested to here
- New ideas can also be directly posted and discussed here - go ahead!
So far we have:
- At any point in time the user is told what to do next.
- Wherever user input is required, options are explained. A default value is investigated and offered where it makes sense (e.g. for the webserver document root).
- Errors are handled as verbose as possible. Wherever possible, hints on a solution or links to further help are given.
- The setup process requires as few changes of media as possible (shell script, sql statements, ftp, web interface)
- Wherever possible, setup and administration is handled through a web interface
- Tiki setup avoids requiring special skills where possible
- Sometimes it is necessary to introduce concepts that might be new to a user (e.g. permission handling). In that case documentation is sufficient so a non-technical user can still follow.
- Technical requirements are minimal (like ftp-access to a server and a shared database); there is sufficient documentation on how to deal with restricted environments
- Tiki is as independent of the environment as possible, such that it feels the same regardless what hardware or operating system it runs on.
- It is easy to create a Tiki instance that looks and feels like it was custom tailored for a specific user group (e.g. teaching, documentation, fanpage, team coordination) - see TikiProfilesDev and ContentPacks.
- In particular, features or extensions that might cause difficulties can easily be disabled, which makes the difficulties magically vanish. (e.g. TikiMap and Graphviz installation)
- Once the user has chosen a certain configuration, the disabled functionality is hidden.
- For example, disabled features don't show in the admin menu ( GettingStartedToDo ).
- The setup process is well documented
- Wherever possible, contributions are done according to the philosophy and guidelines above
- Any improvement is checked whether it could be generalizable.
- User problems and ideas are funneled to the developer space wherever that makes sense (e.g. by providing a link with an error message)
- relevant RFEs and Bug reports find their way to the TikiTeamGettingStarted .
- GettingStartedToDo: Provide a help page for setup errors that guides to the relevant parts of the documentation, Fori, and Bug Trackers. Frequently occuring problems should be handled in an interactive way (Forum, Wiki), so that users can help solving.
- Phase I: Initial Non-Web setup process (now covered in part by setup.sh)
- Whatever can be done inside tiki, should be done inside tiki, via a web interface (see guidelines above). So this process should only cover those actions that can't or shouldn't be done over the web (e.g. for security reasons)
- For every step in this process, there should be sufficient documentation for problematic environments (e.g. setting permissions over ftp if there is no shell access).
- Steps to do:
- Set permissions
- Create database, database user (if applicable)
- Check dependencies (Web Server, PHP, MySQL,...)
- ? what else?
- scripts for specific platforms to make that process even easier: InstallTikiPackages
- Phase II: General Setup through web interface (now covered by tiki-install.php)
- including db table creation
- Phase III: Specific configuration, also web based:
- Selection and setup of Features, Groups, Users, Permissions
- InstallMultipleTikis (at the moment InstallVirtualHosting, not implemented as webbased procedure)
- TikiProfilesDev, ContentPacksDev (not yet implemented)
At the moment, we have a working setup process, that doesn't fulfill many of the guidelines above. Documentation is only a small README in the distribution and what we have here under InstallTiki... Way to go, yeehaaaa!
- For Release 1.7: Working install help environment under InstallTikiHelp, dedicated to help on 1.7 problems
- For Release 1.7.1: Improved webbased guided install
- How fast we can implement the other items in the outline above will depend on how TikiTeamGettingStarted evolves...
- I suppose there will also be other new cool aspects we will implement; Lorinc already brought great ideas. Watch InstallTikiDev !
See GettingStartedToDo .
- phpgroupware: good setup process
- gallery: great setup process! even somebody as inept as me as sucessfully installed this numerous times
- Since the first run is slower (creating templates) we could add teh following so users don't have to modify their php.ini "When called, set_time_limit() restarts the timeout counter from zero. In other words, if the timeout is the default 30 seconds, and 25 seconds into script execution a call such as set_time_limit(20) is made, the script will run for a total of 45 seconds before timing out. " http://www.php.net/manual/en/function.set-time-limit.php
- EasyPhp is GPL. We could make a special edition for a double-click Tiki install
- Bug : Installation : IIS (Windows) glitch I'm not sure this is the ideal place to report this bug - Chealer
install script should check and report on
- php version
- imagick or gd availibility
- available disk space
- writeable directories
More.groupware is pretty good