UESPWiki:Development

This is the index page for all things related to development at the UESP including the wiki and all other resources it offers.

Resources

There are a variety of UESP developer related resources and articles on the wiki and elsewhere as listed below:

• General

• BitBucket Source Code Repository
• dev.uesp.net -- Dev wiki used for testing purposes.
• dumps.uesp.net -- Regular XML dumps of the wiki.
• monitor.uesp.net -- Zabbix server monitoring.
• Upgrade History -- A list of major changes on the site.
• Dev History -- A list of major changes on the development site http://dev.uesp.net.
• Services -- All the various services the UESP offers.

• Dev Resources

• Daveh/uespdeploy

• Map Related Development Notes

• ESO Map Design
• Skyrim Map Design
• Oblivion Map Design
• Morrowind Map Design

• Old

• Database_Outage_
• Database_Download
• File_Database_Design
• Dedicated_Database_Server
• Backup_Plan
• MediaWiki 1.14 Upgrade
• Upgrade_Path
• Server_Upgrade
• Server_Upgrade/August_2008
• Daveh/Wiki Upgrade 1.22
• Daveh/Files1_Setup
• Server_Setup
• Server_Setup/Squid1_Feb2010

Developers

• Daveh -- Site owner, server administrator, general dev (maps, Eso item/data, MediaWiki, etc...).
• RobinHood70 -- MediaWiki and general dev.

Source Code Repository

Our source code is publicly available at https://bitbucket.org/uesp. Note that we are currently in the process of creating the code repositories there and not all source code is currently available or in a well organized state.

Dealing With Secrets

One thing to keep in mind when working with any of the source code is that it is publicly available to everyone through the repository. Configuration parameters such as passwords, keys and other secrets must *not* be contained in any source code file. Such 'secrets' can include things like:

• Passwords
• Keys
• Usernames
• Database names
• Host IPs
• Other sensitive information

All such information should be removed from the source code and put into a secrets file which is then included by the necessary files.

For example the secrets file /home/uesp/secrets/wiki.secrets might look like:

  <?php
      $myWikiUser     = 'username';
      $myWikiPassword = 'something123';
  ?>

and would be included and used in LocalSettings.php like:

   require '/home/uesp/secrets/wiki.secrets'
   $wgDBUser     = $myWikiUser;
   $wgDBPassword = $myWikiPassword;

Thus, when LocalSettings.php is put into the source code repository it doesn't contain any information which would compromise the security of the server. All such files should be named with the .secrets extension and ignored by source control. For example in Mercurial the .hgignore file should include:

   syntax: glob
   *.secrets

Currently the secrets files are stored on all content servers under /home/uesp/secrets/ which is only made accessible to UESP admin shell accounts and is not publicly readable.

ToDo

If you are not a UESP dev and think you have an item that belongs here feel free to discuss it on the Administrator_Noticeboard.

Outstanding Issues

• [[UESPWiki:Administrator_Noticeboard#Wiki_Upgrade_to_1.22.15|]] -- Issues related to the wiki upgrade to v1.22.
• Deprecated MW Calls -- When enabling debugging/profiling on MW and looking at the debug log there are a few deprecated messages related to the UESP custom code (MetaTemplate, UespCustomCode, etc...). These should be looked at are corrected before the next wiki upgrade.
• XML Dumps -- The XML dumps at http://dumps.uesp.net broke after the recent update to v1.22 and need to be fixed.

Long Term Items

• Source Code Organization -- A few projects on the BB repository should be broken up into separate projects. All custom extensions in the MediaWiki project should be their own. The EsoApps project should be looked at (at least uespLog should be its own project). Install uploads should be added for all releases. Version tags should be looked at and added as needed.
• Wiki Upgrades -- The wiki should be upgraded to the latest version. We should do it piecemeal, one version at a time (i.e., 1.23.x, 1.24.x, 1.25.x, etc...) since the most time consuming issue at the moment are post-upgrade issues. Doing it one major version at a time spread outs these issues over time and would help prevent larger issues from showing up.