WikiDB/CHANGELOG

From TestWiki
< WikiDB
Revision as of 15:34, 24 August 2013 by HappyDog (Talk | contribs) (Release notes for r848.)

Jump to: navigation, search

This page lists the changes between releases. Newer versions are on top.

Code re-factoring and other non-functional changes are not listed.

v3

r848

This update fixes the following two issues:

  1. ParserOptions::setUseDynamicDates() was removed in MW 1.21, which meant that saving a page with a <data> tag in would cause a fatal error and the data would not end up in the DB.
  2. Numbers were not being sorted correctly and equality comparisons may have failed when the part after the decimal point contains leading or trailing zeros.
    • 1.1, 1.01, 1.001, etc. were all treated as equal to 1.1
    • 1.1 and 1.10 were *not* being considered as equal

This update also added a --force option to the RefreshStaleData script, which can be used to force all rows to be marked as stale prior to running the update. This is useful in situations where neither table data nor article data needs to be reparsed, but we want to rebuild tblFields, for example if the FormatForSorting code has changed for an existing data type, as is the case with the second issue, above.

Most users won't have been affected by either of the issues here, but if you think you may have been you are advised to run the appropriate update script:

r844

This is a compatibility upgrade. It is also the first release of WikiDB to no longer support PHP4 or MediaWiki versions below 1.7.

  • WikiDB no longer supports MW 1.6.x or below. A fatal error will be raised if you install WikiDB on an unsupported version of MW, with advice about upgrading. The previous version (v3, r816) is still available to install on older wikis, if required.
  • As a consequence of the above, PHP4 is also no longer supported. MW 1.7 and above require PHP5, so this is now also the minimum requirement for WikiDB.
  • Because we no longer support PHP4, I have been able to mark our static calls as such, using PHP5's static keyword. This means that WikiDB now works without errors when E_STRICT error reporting is enabled.
  • I have made a number of other compatibility fixes for new MW versions, so it now runs properly on MW 1.21 (previously special pages were broken, due to architectural changes to MW). I also fixed some (but not all) 'deprecated' notices, which should hopefully reduce the risk of future breakages, when these deprecated functions are removed.

r816

This version just fixes a single bug. If you already have WikiDB installed and working, there is no need to upgrade.

  • In MW 1.17 and above, the installer no longer adds code to set the include path in LocalSettings.php. This caused a fatal error in WikiDB due to it being unable to find some files. Now it explicitly looks in the right place and does not depend on the include_path setting. This bug only affected fresh installations of MW >= 1.17. Upgrades from previous versions are unlikely to have been affected.

r792

  • Various compatibility improvements - WikiDB should now work properly on MW 1.20.
  • At last, we have an enhanced syntax for the <repeat> tag, which allows you to specify optional header/footer sections. This means that custom table output is now possible.
  • There is a new config variable, $wgWikiDBDefaultClasses, which can be used to apply styling to WikiDB data tables.
  • Field names are now handled consistently across the system, and are properly sanitised in all situations. Specifically, we now enforce the following restrictions:
    • White-space at start or end is now always removed.
    • Mustn't start with an underscore, as this is reserved for internal use. Underscores are therefore stripped (so FieldName and _FieldName are equivalent).
    • Must be <= 255 characters along, for DB storage reasons. Longer names are usable, but will be truncated, and so fields must be unique within their first 255 characters (unlikely to be a problem!).
    • Fields can't contain [, - or : characters. These indicate the end of the field name in a table definition (and the start of some other part of the definition) so they can't be used in other contexts either. In this situation, the name is considered completely invalid and will be ignored.
    • Mustn't be blank - blank names (after sanitising) are considered invalid and will be ignored.
  • I've made a whole bunch of fixes to the built-in data type handlers:
    • The Min/Max parameters for number fields weren't working correctly.
    • Numeric fields now only accept completely valid numeric representations. Previously it used PHP's is_numeric() function, so entries like "23 Skidoo" would be read as the number 23, whereas now they are invalid (resulting in an empty field).
    • Data in numeric fields are now output in the appropriate format for the user's locale, rather than always in English format.
    • 'integer' fields now use float values internally, rather than integers, which means a greater range of numbers can be represented.
    • 'image' fields weren't recognising all aliases for the image namespace, only the canonical name and the local name. Since 'File:' was introduced as the canonical namespace this meant that 'Image:' was no longer recognised. We now correctly identify all valid aliases.
    • 'image' fields were not matching the namespace in a case-insensitive manner, so 'File:' would be recognised as an image, but 'file:' wouldn't be.
    • 'link' and 'image' fields are now sorted by their canonical name, meaning "Image:My Pic.jpg" and "Image:My_Pic.jpg" are now treated as equivalent.
    • Fixed output of 'image' fields so that if they refer to an image that doesn't exist we get a proper red link. Previously the link would be there, but the text for the link would always be "75px".
  • Fixed a bug whereby the field aliases table on a table definition page might display strangely under certain circumstances.
  • If you view data for a table that is a redirect, you now see a link pointing you to the data tab for the actual table where the data has ended up. Previously you just got a 'no data' message.

The improvements to field name sanitising and the new <repeat> tag syntax means that there may be certain unlikely situations where your DB may hold stale data. (Specifically, if you happened to use the new syntax in an old version of WikiDB, or if you had any field names that will be sanitised differently under the new rules). It is unlikely that this will affect you, but if you think it does - or you want to be certain - you should run the RebuildWikiDB script to ensure your DB holds the correct values.

r668

  • More compatibility fixes for MW 1.18. Data wasn't saving properly, and the 'viewdata' tab wasn't appearing in the table namespace. Both issues fixed.

r661

  • Compatibility fixes for MW 1.18 (plus a couple for 1.17). There has been a really annoying habit recently of pointlessly breaking backwards-compatibility with each new MediaWiki release. I'm going to avoid the temptation to write a long rant about this, but it is getting really, really frustrating!
  • Performance improvements: I have massively improved the performance of the <repeat> tag. For a test with a dataset of about 4000 records, and a <repeat> tag that pulled 60 records from it, the execution time has been improved from 1.017s to 0.025 - that's about 40 times faster!
  • As part of the above fix, I've rewritten the query code so that it no longer uses temporary tables. Therefore the CREATE TEMPORARY TABLES permission is no longer required for your database user.
  • Improved i18n by moving a lot of hard-coded strings into system messages, customisable via the MediaWiki namespace. There's still more work to be done, but it's a big improvement.
  • Added pagination to all special pages, and to the data tab.

You should not need to update your database if upgrading from the previous release. Note that if you have customised any UI strings via the MediaWiki namespace then you may need to revisit this, as a few strings have been renamed and a couple have been combined into one (via use of the inline {{#PLURAL:}} function).

r620

  • Some compatibility fixes for MW 1.17 and MW 1.18
  • Fixed bug whereby namespaces in the 'SourceArticle' column were in the language of the user viewing the page, rather than the wiki's language, meaning that the links were broken if these were not the same.

r495

  • Fixed bug that caused table definitions to not be saved.

You should run UpdateTableNS.php to fix any missing definitions caused by the above bug.

r489

  • Compatibility fix.
  • Added README.TXT and LICENSE.TXT to distribution.

r485

  • A few compatibility fixes.

r480

This is the first update to WikiDB for about a year and a half, partly due to a very busy life, and partly due to this being quite a major reworking of some of the core internals. This new version includes the following new features:

  • Proper alias resolution (you can now rename tables and watch as the data magically follows the redirect).
  • An extension of the <data> tag which allows you to define multiple data rows within a single tag.
  • Fixes to the sorting/filtering algorithm so that the <repeat> tag now works a lot better (and hopefully a lot faster!).
  • Updated the way parsing works when saving a page. It is now a lot less hacky and less likely to break if the MW parser object is updated. It also now ensures the article is parsed consistently in all cases (previously it was done differently when saving to when viewing the page, which in some rare cases could result in a mismatch between the data you see and what is actually in the DB).
  • A number of display bugs are now fixed, particularly in relation to the way the SourceArticle field was output.
  • Much less chance of SQL injection.
  • We now have maintenance scripts! No more copy/paste SQL! No more null edits to fix parsing issues!
  • A whole load of other little bug fixes, and a general code cleanup.
  • No doubt some other little bits I've forgotten.

v2 / v1

Changelogs were not kept for earlier versions, I'm afraid.