For example, a user may create a date/time profile field and set the 'Start year'
field to '2012'. Another user, using the Hijri calendar, may edit the name of
this field. They visit the settings page and in this case the date '1/1/2012'
is converted to '7/2/1433' in Hijri. So, the year '1433' is then displayed.
The user then changes the name of this field and saves the form. This is where
the issue occurs, as the date '1/1/1433' is converted into Gregorian, which
converts to the year '26/09/2011', so the year '2011' is saved in the DB, not
'2012'.
1) Moved the calendar types location to a sub-folder in the calendar directory.
2) Removed/moved language strings.
3) Removed calendar types that should be downloaded as plugins.
4) Removed a Non-English language pack for the Gregorian calendar type that
should be downloaded separately.
5) Removed custom files responsible for checking for updates and uninstalling
calendar types, which should be done by core.
6) Removed JS from the calendar_month block as there is no non-JS alternative
provided and the JS written does not make use of the YUI library to ensure
multiple browser support.
7) Removed code from the base class responsible for creating timestamps that
are saved in the DB.
8) Added PHPDocs.
Note: In the original patch we are editing core functions responsible for saving
time in the database in the calendar base class. This is very dangerous, we do
not want to touch these functions as it could cause a complete fubar of the
database. There are places we are forcing the use of the gregorian calendar as
we are passing dates generated by the PHP date function, where as sometimes
we pass dates from usergetdate (which was being overwritten to return the
date specific to the calendar). We can not expect third party modules to
change the calendar type depending on the format they pass to these functions.
This reverts commit fbb31b0f905c8859cc4f559f4f8148769367ece6.
This reverts commit c111b9f3aeea98542213ff530f59291fd45d1245.
This reverts commit 8afb9b7c4f2bfbb336b3e3af580cb14d32b0e917.
This issue has failed testing and integration will be delayed.
Currently we have two options for custom profile fields 'Unique' and 'Required'
If value s not entered for unique and not required field then we should allow
duplicate empty values. If value is entered then we should check for unique input.
In case field is unique and required then it should be always checked as required
field can't be empty.
* Fixed up database installation and upgrade code
* Reverted some whitespace optimisations to minimise conflicts
* Optimised commits made by Mark to reduce complexity and add tracker issue numbers
