Developer forum

Forum » CMS - Standard features » Date controls in Admin result into broken CMS pages, no clue why and how to solve ...

Date controls in Admin result into broken CMS pages, no clue why and how to solve ...

Peter Leleulya
Peter Leleulya
Reply

Our customer notified us that their production CMS 9.7.5 was 'broken' ...

It seemed that date controls in the admin section caused troubles, a bit as described in: https://doc.dynamicweb.com/forum/cms-standard-features/cms-standard-features/editing-pages-paragraphs-in-backend

Unfortunately the 'answer' in this forum ticket was no help to us....

This is the stacktrace WE get when clicking on any content page:

A similar problem occurs to product detail page.
Orders don't seem to be a problem while having date controls too.

At first I checked if our acceptance environment had the same problem, and it did!
This environment is not the same as the production environment, but has the same setup.
So we luckily had a non production environment to test with.

Then I checked if out local GIT version had the same problem, but there was no issue found.

If I went to a page in the admin on our acceptance server and commented out the control the problem was gone, but this is not a fix ofcause.

We tried the following:

  • I attached the acceptance database to my local website, the problem did not occur ... so we don't think it is a database or data issue
  • We checked the local and acceptance globalsettingsfile with winmerge, they were identical
  • We checked the local and acceptance web.config with winmerg, they were idenntical apart from connectionstring and debug settings
  • We checked IIS, just to be sure, but could not find anything out of the ordinary
  • We checked the DLLS, no issues found
  • We triggerd a new build and release, this didnt help
  • We removed all dlls and redeployed, this didnt help
  • The admin had last been changed on 28-8-2019, so that could not be the problem
  • We zipped the acceptance admin and attached it to our local application, then there was no problem
  • We zipped the entire acceptance environment en attached the iis to it and fixed the 12700 connectionstring, THEN THERE WAS NO PROBLEM !!!
  • We reinstalled the licence with both client- and full licence, it did not help.
  • We checked the server culture and language, seems to be OK
  • The last server update was on september 16 and the last reboot august 18, so there was no server update to f this up (we cant reboot it by ourselves)
  • We made a copy on the acceptance server with a unique url, then the problem remains
  • We checked other DW applications on the same server with no problem.

At the System information screen we get under the server heading the server time with a dutch format, while locally it is in English.
Can this be an issue? And if so, what can we do?

We really have no clue what to check anymore ....
We think it must have to be SOMETHING on the server, but have no clue WHAT ...

Any ideas ???

 

 

 

 

 


Replies

 
Nicolai Pedersen
Reply

Aw, what a pain in the ass!

Can you zip and attach the web.config for this solution?

Thanks, Nicolai

 
Peter Leleulya
Peter Leleulya
Reply

Hi Nicolai,

Yes I can.
I attached the one from the acceptance environment.

 
Nicolai Pedersen
Reply
This post has been marked as an answer

Hi Peter

I see nothing that I directly can say is wrong in web.config.

Try these things - a couple of wild guessing...

  • Delete temporary .net compile files - somewhere down in %SYSTEMROOT%\Microsoft.NET\Framework\**
  • It can be a dll version issue - maybe a version number in web.config vs. the one in the loaded dll. You can try to remove stuff and references from web.config in bits to see if that can locate a place it could happen.
  • If you copy the site to another folder and IIS instance on the same server, same happens?
  • Any subfolders in /bin?

Try to change the system.web/compilation section in web.config to this:

<compilation debug="false" targetFramework="4.7.2">
      <assemblies>
        <add assembly="netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51"/>
      </assemblies>
      <expressionBuilders>
        <add expressionPrefix="GS" type="Dynamicweb.Controls.Design.GlobalSettingsExpressionBuilder, Dynamicweb.Controls" />
      </expressionBuilders>
    </compilation>
Votes for this answer: 1
 
Imar Spaanjaars Dynamicweb Employee
Imar Spaanjaars
Reply

>> At the System information screen we get under the server heading the server time with a dutch format, while locally it is in English.
Could that be related? What happens if you change your regional settings on your dev machine to the same as the server?

 
Peter Leleulya
Peter Leleulya
Reply

We discovered that setting the targetFramework to 4.5 fixed things.
But the 4.7.2 target with the netstandard addition as mentioned by Nicolai also worked, so we obviously went for that.

@imar fiddling with culture and language settings didnt help a bit ...

 

UPDATE: 

I found out we didnt need the netstandard after all.
The problem was a targetFramework (4.7.2) attribute in the httpRuntime node of the web.config

Removing the targetFramework attribute from the httpRuntime node fixed it all.

When adding a targetFramework 4.5 to the httpRuntime it also works ...

What is advisable? no targetFramework or the 4.5 version added to the httpRuntime?

We think runnng in compatibility mode might cause issues with async and such, and can have less performance ...

 
Nicolai Pedersen
Reply

Hi Peter

Great finding. I would remove targetFramework as all of it runs on the same runtime and it is just a matter of available .net libraries that is the difference - and the exception you would get from that would be missing system.* something - and that would be easy to understand and fix. Also that error would only be on servers wihtout 4.7.2 installed, which would only be really old not-updated servers...

I am not into the details of compatibility mode - but if it works without, go for that!

BR Nicolai

 

You must be logged in to post in the forum