CMS Made Simple Forums

Today I started to check if I can upgrade a big website with a lot of modules to CMSMS 2.x
One of the first things on the todo-list was to upgrade modules. Since ListIt2 is no longer supported, I tried to install LISE and start the import process.

That went well for all instances but one.
When I go to the admin section of that module I get the error messege:

DateTime::__construct(): Failed to parse time string (@10:15) at position 3 (:): Unexpected character
#0 /home/p4d/domains/paarden4daagse.nl/public_html/cms2/modules/LISE/lib/class.lise_datetime_utils.php(70): DateTime->__construct('@10:15')

My guess is that LISE expects a unix timestamp in stead of the time 10:15 and that the import script does not convert it?

Second thing is that after I solved that in the database, I tried to edit the time value to lets say 11:30 via the admin section of the LISE-instance, then open the item again, the value is changed to 2 hours earlier, so it says 09:30. LISE does that every time you hit save or apply.

I will create a bugreport from which I will point here. It was easier to explain in a forum post.



System information:
----------------------------------------------
Cms Version: 1.12.2
Installed Modules:
CMSMailer: 5.2.14
FileManager: 1.4.5
MenuManager: 1.8.7
MicroTiny: 1.2.9
ModuleManager: 1.5.8
News: 2.15.2
Search: 1.7.13
FormBuilder: 0.8.1.4
Gallery: 2.1.6
FrontEndUsers: 1.26
CustomGS: 3.0
CGExtensions: 1.53.13
MleCMS: 1.11.4
Banners: 2.9.1
CGSmartImage: 1.21.5
GBFilePicker: 1.3.3
Gbook: 2.2.2
FAQ: 2.0.1
ListIt2: 1.4.1
ListIt2Programma: 1.4.1
CMSPrinting: 1.0.5
ThemeManager: 1.1.8
CGSimpleSmarty: 1.10
CGJobMgr: 1.3.4
NMS: 2.12.2
ListIt2NMSitems: 1.4.1
ListIt2Routes: 1.4.1
FormBrowser: 0.5
Captcha: 0.5.3
JMFilePicker: 1.0
LISERoutes: 1.2.1.1
LISENMSitems: 1.2.1.1
LISEProgramma: 1.2.1.1
LISE: 1.2.1.1

Config Information:
php_memory_limit:
process_whole_template:
max_upload_size: 64000000
url_rewriting: mod_rewrite
page_extension: .html
query_var: page
image_manipulation_prog: GD
auto_alias_content: true
locale: nl_NL
default_encoding: utf-8
admin_encoding: utf-8
set_names: true

Php Information:
phpversion: 5.5.37
md5_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_STRICT: 2048
E_DEPRECATED: 8192
memory_limit: 256M
max_execution_time: 30
output_buffering: On
safe_mode: Off (False)
file_uploads: On (True)
post_max_size: 64M
upload_max_filesize: 64M
session_save_path: No check because open basedir active
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)

Server Information:
Server Api: apache2handler
Server Db Type: MySQL (mysqli)
Server Db Version: 5.6.29
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable
Server Time Diff: No filesystem time difference found

----------------------------------------------

I'm sorry, there already seem to be some bugreports on these issues:
http://dev.cmsmadesimple.org/bug/view/11012
http://dev.cmsmadesimple.org/bug/view/11071

It's a known issue but not exactly a bug per se... There were a few changes introduced in LISE 1.1 wrt the datetime fielddef. Previously in LI2 and LISE, the datetime field was saved on the DB as text on the locale format selected on the settings of the field. This meant that chronological sorting was only possible depending on the format selected as in reality was the sorting was alphabetic. Most of the formats can't be used for this purpose. LISE 1.1 introduced a change: all datetime would be converted to a unix timestamp allowing to sort chronologically, but with an option to keep backwards compatibility, still being saved as text in the DB in both cases. Why? Because IIRC the original field was using JQuery UI data formats and there is no reliable conversion possible to unix timestamp from those, at least not that I know of... There is no simple solution and even the UDT ajprog shared solves some but not all of the conversions as far as I could test. But it works for some of the formats, which means that some of the users having this issue got lucky (thanks ajprog ). For the rest of the users there are not many options other than keep the backwards compatibility.
In any case, if anyone finds a reliable conversion method please let me know (I searched and tested for days and couldn't find one), in which case I'll include it in the module.

Thanks JoMorg.
Do you think both issues are related to each other?
You recommend to not use the backwards compatibility option?

Jos wrote:Do you think both issues are related to each other?

Ha! I'm getting old... I had skipped past the second part of your original post! My bad, sorry...
Yup, possibly related and that, yes is probably a bug. I'll have to try to reproduce it, but I can see some code where it could potentially trigger something like that.

Jos wrote:You recommend to not use the backwards compatibility option?

On imports from LI2 and upgrades from LISE pre-version 1.1 I'd use the backwards compatibility when the conversion to unix timestamp is not practicable for some reason and chronological sorting of items is not needed. Otherwise clear that option on settings as in new instances with fresh data shouldn't need it set.
I recommend people to test (and read about) format conversions between JQuery UI datetime formats and unix timestamp. Some may eventually fail, and there no easy solutions as I said.

Thanks, for the site-upgrade I will stick to the backwards compatibility option then. With the udt of Jeff all works fine for me