Child pages to this one:
Table of contents of this page:
- Team members
- Release responsibilities
- Ongoing responsibilities
- Fix and close
- 1.1. Review backup situation for non-Tiki instances
- 1.2. Add files stored on disk to the Pre-Dogfood server
- 1.3. CDN
- 1.4. One-time clean-up of prefs to be a community site
- 1.5. irc.tiki.org wrong favicon
- 1.6. irc.tiki.org blank pages of some search
- 1.7. transition from tikiwiki.org to tiki.org
- 1.8. Activate the removal of www for all sites
- 1.9. Clean up permissions on tiki.org
- 1.10. Images lost on dev.tw.o
- 1.11. Rewrite Rules
- 1.12. dev.tiki.org -> delete from user list all users that are not necessary here
- 1.13. Delete a pic
- 1.14. Move calendar data from dev to info site
- Major projects
- 1.1. Migrate to Allura
- 1.2. Show.tiki.org
- 1.3. Move phpxref to own subdomain
- 1.4. WebSVN
- 1.5. Doxygen
- 1.6. ApiGen
- 1.7. phpDocumentor
- 1.8. Dogfood TRIM
- 1.9. Round Robin / Redundancy / Disaster planning for all *.tiki.org content
- 1.10. Setup a monitoring solution
- 1.11. Implement Single Sign On (SSO) on 6 main sites.
- 1.12. Code stats
- 1.13. Community Mail Server
- Related links
- Progressively update each Domain to the new version, and the Dogfood Team's plan.
- The goal is that all major sites are upgraded before it's released.
This page is to coordinate work and list requests about various aspects of *.tiki.org sites and community tools
This has previously been done by email. We will do it wiki way so at any given time, we'll know what needs to be done.
This is not a list of feature requests, which should be done at: http://dev.tiki.org. If it's Tiki bug, it's ok to put below but with a link to dev.tiki.org as well but know that while the infrastructure team can help detect/confirm a bug, it is not expected to correct bugs, but to update the sites as soon as they are corrected.
Do not put any security or sensitive info below. Instead, contact http://security.tiki.org
In the past, it's happened that we had specialized changes to Tiki (ex.: message templates, custom plugins, etc.). And then, sometimes, these get wiped with a clean install of Tiki. While we should try to stay as close as possible to Tiki code dogfood, when we do not, it should be documented or we use TRIM/SVN and have it make a report of all diffs (or something)
Because of the special use case on *.tiki.org, we may have to maintain special .htaccess files...
Please create the wiki pages if the access has been or should be modified
- htaccess doc
- htaccess dev (will need calendar redirect)
- htaccess community
- htaccess profiles
- htaccess info
- htaccess themes
- All our sites should be recent versions of the branch
- The revision number should be visible so everyone knows to indicate if the see a bug
- Each host should make send backups to another. Can be done by TRIM
- Managing the DNS info for the various Domains MarcLaporte, and Amette and Fabio have access
- Domain names MarcLaporte
- tiki.org emails: Frank or MarcLaporte
- SSL: We once had a wildcard SSL, but are moving to Let's Encrypt, and thus depends on server
- Community Server renewal, payments, etc. (Nelson?)
- Now, it's only files in the DB
- Setup a CDN for each *.tiki.org site as this will improve performance
- Tools like http://tools.pingdom.com/fpt/ report "Serve static content from a cookieless domain"
In collaboration with Infrastructure Team:
- All users should accept user messages
- User messages should send notification emails (bounced to Community Team)
- Can group members broadcast members of their own group? (it should)
- Setup permanent redirect from tikiwiki.org to tiki.org
- will redirect of http://tikiwiki.org/stable.version cause an issue? (like InterTiki)
- Finance Team has on todo to transfer ownership of tikiwiki.org, and thus, this will impact this team.
New option in Admin -> General -> Navigation "Domain prefix handling" which would be nicer than the "Are you lost ?" at http://www.doc.tiki.org/
Tiki.org has a lot of legacy perms. Ex.: workspace (aulawiki), homework, jukebox, etc. They should be removed from http://tiki.org/tiki-objectpermissions.php along with any assignments. Todo: Take a Tiki 5.x clean install, and compare.
and two images here: http://dev.tiki.org/Translation+Editor+Revamp (tiki-download_wiki_attachment.php?attId=88) perhaps issue between 5.0 and 5.1 ?
Still available for old server. (ask Marc for access)
I posted a comment here with a link to http://doc.tiki.org/categories and I get http://doc.tiki.org/tiki-browse_categories.php instead of http://doc.tiki.org/tiki-index.php?page=categories
same problem with http://doc.tiki.org/calendar
dev is ok:
Check with Rick 1st
With a persistent rewrite rule . Now: Upcoming Events
Migrate to Allura with the Developers Team
From de.tiki.org/xref-trunk/ to phpxref.tiki.org and make sure to add a redirect 301 for search engines
Eventually, we will loose
in favor of https://sourceforge.net/projects/allura/
We used to have http://de.tiki.org/dox-trunk/html/, but it's gone now. Do we re-install? If so, at doxygen.tiki.org and make sure to add a redirect 301 for search engines
Is it worth setting it up?
TRIM handles backups so offsite backups are inherent. Not as important to have Round Robin / Redundancy / Disaster planning for all *.tiki.org content.
- http://dev.tiki.org/tiki-admin.php?page=performance for warnings like -> Small amount of memory allocated to APC. Verify the configuration. The values to increase are apc.shm_size (for APC) or xcache.size (for XCache).
Monitor for broken links. Ideally, we'd have this in Tiki
- Figure out svnplot