Change Date Format in Properties Tab - (TinyMCE bug?)
I need to change the format for all dates displayed in the properties tab of each node ... the created, last published, and last edited dates, etc ... to American style of mm/dd/yyyy. Umbraco 4.7.1, IIS 7.5
It seems like it shouldn't be that hard, but we've spent a day and half on it and haven't made much progress.
which immediately resulted in almost all nodes of a document type that uses Richtext Editor/TinyMCE, which is almost all nodes in the site, to blow up (although the date format did correctly change for nodes of a document type that doesn't have TinyMCE):
Server Error in '/' Application.
String was not recognized as a valid DateTime.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.FormatException: String was not recognized as a valid DateTime.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[FormatException: String was not recognized as a valid DateTime.]
System.DateTime.Parse(String s) +6364770
uHidesy.Umbraco.usercontrols.uHidesy.uHidesy.LoadSettings() in D:\_PROJECTS\uHidesy - Property Hider\Branches\1.13_noDesc\Umbraco.Web\usercontrols\uHidesy\uHidesy.ascx.cs:102
uHidesy.Umbraco.usercontrols.uHidesy.uHidesy.OnLoad(EventArgs e) in D:\_PROJECTS\uHidesy - Property Hider\Branches\1.13_noDesc\Umbraco.Web\usercontrols\uHidesy\uHidesy.ascx.cs:44
System.Web.UI.Control.LoadRecursive() +71
System.Web.UI.Control.LoadRecursive() +190
System.Web.UI.Control.LoadRecursive() +190
System.Web.UI.Control.LoadRecursive() +190
System.Web.UI.Control.LoadRecursive() +190
System.Web.UI.Control.LoadRecursive() +190
System.Web.UI.Control.LoadRecursive() +190
System.Web.UI.Control.LoadRecursive() +190
System.Web.UI.Control.LoadRecursive() +190
System.Web.UI.Control.LoadRecursive() +190
System.Web.UI.Control.LoadRecursive() +190
System.Web.UI.Control.LoadRecursive() +190
System.Web.UI.Control.LoadRecursive() +190
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +3064
Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.272
although new nodes seem to work alright.
Next, I made a new /umbraco/config/lang/en.xml, name it us.xml, and changed
then changed a user's language to English (us) and got similar results.
If I create a new node (of a document type with TinyMCE) while using culture="en-US", it breaks almost all nodes (of a document type with TinyMCE) permanently, if even I switch back to culture="en-GB".
3. Richtext Editor/TinyMCE
In the previously-mentioned promising instructions, Immo Wache indicates that several files need to be changed to update TinyMCE. I changed them all according to the plan, upon starting this whole process over for a second time found even more .js files than listed, and with culture="en-US" being used in conjunction with the creation of a new nodes (of a document type which uses TinyMCE), previous nodes break again with the same error.
4. My current thoughts
First off, why is this so hard? Second, since I do get favorable results for nodes of a document type that doesn't have TinyMCE, it seems like I'm on the right track if I can get TinyMCE to work around this. I can go back and forth with culture="" and un-break the 'String was not recognized as a valid DateTime' error, but once I create a new article under the culture="en-US" everything breaks to the point that I have to restore a backup from two days ago. I'm also thining about the date picker with time datatype.
Do you see anything I missed above? Any help would be DEEPLY appreciated.
Thanks Euan for your response ... I ended up fixing it before checking server! I restore a backup from a days ago and found the right way to do it. The core of the problem wasn't TinyMCE, but one of my favorite packages uHidesy.
Since we don't need GB and US time format, I kept en.xml and changed the top line to
At this point in the content tab, many nodes were borken, but not all. I took careful inventory and listed everything. About 2/3 of the nodes threw the error I mentioned above, and the other 1/3 loded fine and had the right US date/time format that I was trying to get. I was surprised to find that many of the working nodes also had TinyMCE, even though I thought that was the problem.
I sifted through the data some more and discovered that, although nearly every had some form of uHidesy control, the nodes that were working didn't have a uHidesy field associated with them in the database. I went in to the document type of node that was broken, changed uHidesy form the uHidesy control to the standard label control, and the problem went away.
However, uHidesy is indispensable for this project! In order to get it to work, I simply went to each datatype, deleted the uHidesy property, then put it back in with the exact same settings. I didn't have to go through the tabs again and apply uHidesy - everything was the same. Now, uHidesy works great and the back office is in en-US culture and all is well with the world.
Change Date Format in Properties Tab - (TinyMCE bug?)
I need to change the format for all dates displayed in the properties tab of each node ... the created, last published, and last edited dates, etc ... to American style of mm/dd/yyyy.
Umbraco 4.7.1, IIS 7.5
It seems like it shouldn't be that hard, but we've spent a day and half on it and haven't made much progress.
1. <globalization>
I changed
to
and
but no change.
2. en.xml
As per these promising instructions, I changed the first line in /umbraco/config/lang/en.xml from
<language alias="en" intName="English (uk)" localName="English" lcid="" culture="en-GB">
to
<language alias="en" intName="English (us)" localName="English" lcid="" culture="en-US">
which immediately resulted in almost all nodes of a document type that uses Richtext Editor/TinyMCE, which is almost all nodes in the site, to blow up (although the date format did correctly change for nodes of a document type that doesn't have TinyMCE):
although new nodes seem to work alright.
Next, I made a new /umbraco/config/lang/en.xml, name it us.xml, and changed
<language alias="en" intName="English (uk)" localName="English" lcid="" culture="en-GB">
to
<language alias="us" intName="English (us)" localName="English" lcid="" culture="en-US">
then changed a user's language to English (us) and got similar results.
If I create a new node (of a document type with TinyMCE) while using culture="en-US", it breaks almost all nodes (of a document type with TinyMCE) permanently, if even I switch back to culture="en-GB".
3. Richtext Editor/TinyMCE
In the previously-mentioned promising instructions, Immo Wache indicates that several files need to be changed to update TinyMCE. I changed them all according to the plan, upon starting this whole process over for a second time found even more .js files than listed, and with culture="en-US" being used in conjunction with the creation of a new nodes (of a document type which uses TinyMCE), previous nodes break again with the same error.
4. My current thoughts
First off, why is this so hard? Second, since I do get favorable results for nodes of a document type that doesn't have TinyMCE, it seems like I'm on the right track if I can get TinyMCE to work around this. I can go back and forth with culture="" and un-break the 'String was not recognized as a valid DateTime' error, but once I create a new article under the culture="en-US" everything breaks to the point that I have to restore a backup from two days ago. I'm also thining about the date picker with time datatype.
Do you see anything I missed above? Any help would be DEEPLY appreciated.
Is the server you're hosting umbraco on set to use US format for date time?
Thanks Euan for your response ... I ended up fixing it before checking server! I restore a backup from a days ago and found the right way to do it. The core of the problem wasn't TinyMCE, but one of my favorite packages uHidesy.
is working on a reply...