Pre-Dogfood Server

Managed by the Infrastructure Team and Dogfood Team, this is to have a daily test upgrade of most of our *.tiki.org sites. So anyone can check anytime how stable trunk (the next version) is with real world data. The name relates to our eat our own dogfood policy.

During the duration of the transition SVN to GIT we have a mechanism to synchronise our git repo (master) with our SVN repo (trunk). Here is how to check if SVN is up to date: https://dev.tiki.org/Git-and-SVN-combined-workflow#Status

See also: Pre-dogfood servers for Tiki 26 release process


To check tomorrow's code (trunk) with yesterday's data, you can access the links below. Most of the year, these sites are running trunk, but during the release process, we run the upcoming version. Ex.: branches/9.x is used instead of trunk until dev.tiki.org moves from 8.x to 9.x

trunk (master)

http://next.tiki.org/ This is for tiki.org The cron job for next.tw.o is executed at noon and midnight my time (-6h to get NY time and -9h to get SF time). next.tiki.org is synchronised from Git
As of 2022-11-02, no extra password. But if one is added, it will be:
u: next
p: next

https://dev.tiki.org (25.x) -> See Pre-dogfood servers for Tiki 26 release process
https://doc.tiki.org (25.x) -> See Pre-dogfood servers for Tiki 26 release process
https://themes.tiki.org (25.x) -> See Pre-dogfood servers for Tiki 26 release process

Next LTS

If branding is running on Tiki18 LTS, nextbranding.tiki.org should be Tiki21 LTS, as it's the next likely upgrade
http://nextbranding.tiki.org/ (Full upgrade from live site daily, code update without full rebuild of index every 30 min.) (Powered by Tiki Manager)
u: next
p: next

http://nextprofiles.tiki.org/ (Full upgrade from live site daily, code update without full rebuild of index every 30 min.) (Powered by Tiki Manager) As of 2022-03-03, we decommissioned, and will restore in 2-3 months on another server. This site is not so useful because next upgrade will be in 2024.
u: next

p: next


  • Dogfooding Tiki on our own sites is great to find bugs, but it makes it difficult to work.
  • Say I find a bug on a tiki.org site, is it fixed in the next version, or should I report/try to fix bug?
    • This is very time consuming.
  • Detecting and fixing bugs is much less efficient without real data. We would like to give developers access to a site where they can test a fix, before committing (or very quickly after)

Which is why we have set up a continuous Pre-Dogfood Server. Yesterday's data with tomorrow's code (code in trunk). Ideally, this would be part of TRIM so everyone in the community could easily set this up for themselves, but it's not at this stage.

Setup system for permanent testing of trunk with real data

1- Run a new site ex.: nextdev.tiki.org

    • On a server we can give trusted devs access to test
    • With backup of real data from dev.tiki.org
    • Using trunk

2- Daily update of code (from trunk)
3- Daily refresh of data (from live site)


Make your own pre-dogfood server

The future-proof solution is Clone and Upgrade in Tiki Manager

Alternatively, some other code is here: https://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/doc/devtools/update.dogfoodserver.sh

System Configuration

Use the following as per System Configuration. See also Divergent Preferences in Staging Development Production

Create a tiki.ini file with some or all of the following content
; To avoid bots indexing the site and losing SEO over duplicate content
preference.metatag_robots = "noindex, nofollow"   

; Testing changes shouldn't spam people 
preference.feature_user_watches = n

; Make it obvious to everyone that this is not real data site
preference.sitesubtitle = "Pre-dogfood test upgrade server. Data refreshed daily."

; Set error reporting to all (useful for debugging)
preference.error_reporting_level = -1

; Make error reporting available to all users, not just admins 
preference.error_reporting_adminonly = n

; Here are some less commonly used options. Just uncomment the prefs to be like above by removing the ;

; If you are using memcache in production, you probably want to deactivate for the pre-dogfood server, or at least change the memcache_prefix so the production and pre-dogfood server don't collide
; preference.memcache_enabled = n

; If you are using a Content Delivery Network (CDN), you want to make sure values are not the same in production vs pre-dogfood server
; tiki_cdn = ""
; tiki_cdn_ssl = ""

; If you want to prevent user registrations, uncomment below
; preference.allowRegister = n

; To close the site. Only users with tiki_p_admin permissions can log in.
; preference.site_closed = y

; Closed site message
; preference.site_closed_msg = "This is a development site, not open to the public"

Is enough metatag_robots enough? Or is modifying https://next.tiki.org/robots.txt also necessary ?


  • Upgrade procedure is tested very frequently
  • Makes it very easy to compare old & new interfaces (and people can say what they liked/want to keep about the old one)
  • Make it easier for Tiki community to make a judgment on when to start dogfooding next version on community site.

Potential users

  • All devs: To test before an upgrade. Ex.: They could load test daily and report any feature or performance regressions.

Ideas to improve

  • Continuous Integration Team could set up some tests on pre-dogfood servers
    • A way to receive alerts on major breaking
      • SQL error, PHP error
      • Would need a crawler for early detection of breakage
  • all pre-dogfood servers should indicate in how many hours is next data refresh
  • To make *.tiki.org upgrades easier, to catch regressions sooner, dev.tiki.org could run on monthly updates of trunk code, while nextdev.tiki.org is daily trunk. Before each monthly upgrade, nextdev.tiki.org is checked to catch and fix regressions.
  • Change the domain name from trunk to next, because it's not always trunk, but always next done
  • Tracker item: #4200 - - Compare generated HTML for all *.tiki.org sites between versions (to check for regressions/changes of behavior)
  • Handle _htaccess
    • Use unix file link from .htaccess to _htaccess
  • Find a solution for RewriteBase to avoid " The RewriteBase directive seems not to be set up correctly. This is required for sefurl to function correctly. The current value in .htaccess is / but the base url for this site is /trunk/ "
  • Clear all cache Now part of the shell installer
  • To be able to apply a profile or a System Configuration
  • To do the same thing, but for various profiles.


Upcoming Events

No records to display