I can get it to sync everything except templates. As soon as I turn them on Umbraco exceptions. It would seem that uSync has created a complete backup, but it's hard to say for sure as I have quite a lot of templates. The problem is the exception doesnt detail which template it's having a problem reading. See below...
Sorry it did that, i am trying to reduce the number of blocking errors in usync but it looks like one of the templates is missing a closing div or something and that is making the export upset - if you look in the log files (app_data/logs/umbracotracelog.txt) you should be able to see which of the templates was being processed when the error was thrown.
if that doesn't help turning up the logging in the log4net config (/config/log4net.config) from info to debug will give you a lot more information about what usync is doing.
if you find the template, then please do pass on the details, and i will look at getting usync to be a bit more resilient to the export/import of templates.
That paste was from the tracelog, unfortunately with no indicator as to which file is misbehaving/
Does Umbraco store the actual template in the DB or just pointers to the template files?
Also I wouldve thought CDATA would be enough in your XML to prevent such errors, but it would appear in my case not to be enough. I seem to remember reading somewhere that some characters can still scupper CDATA sections.
Yes sorry missed that - but changing to debug in log4net.config should then list the templates as it goes through them.
yes CDATA should do it but - unfortunately it's not usync that is generating the xml file, it's the core umbraco API. the same one used by packages. Its a bit of a pain because the export/import functions inside umbraco create this file, but as you point out they don't use the template content in the xml to update the template file
The template code is only used on first import - every other import all that is updated is the DB elements which is just the ID, Alias and Parent Id of the template.
For that reason templates are a bit painful to import - I have been looking in later versions at completely removing the dependency on the internal import /export functions for templates but at the moment (well until v7.1.0) you couldn't create the templates programatically with the core API because the Parent ID is internal to the core so you can't set it.
This is changing however and once I've tested that I think usync will move to its own template export/import that just does the IDs - until then the best i can do is fail the import and log it - it's a bit of a catch 22 because you might want to know the background process isn't working but then you don't want a YSOD all over your site because of it.
How do I switch to log4net? I've never attempted it before.
Wow, i'm quite surprised at the import strategy on templates. You'd think as it's all file based Umbraco would just create keys in the DB regardless of first or subsequent imports! Oh well it is what it is and hopefully you'll have something better in place for 7.x going forward. I have to say i'm really looking forward to upgrading our main project to 7. I've done a test build 7.0.4, but I had a lot of issues upgrading the DB, but once I pushed passed the errors, it was great to see such enormous improvements in the UI.
We've all but dumped Courier 2 on our projects because it's just too unreliable, but I still need a robust way of pulling together a local build ready for production, so I'm hoping uSync will be a better fit.
The way umbraco imports is a legacy thing really and to do with the fact that the import/export routines where orgininally written for package creation, so they export everything to be put in a package, and import it back in first time (but not subsequent times) because they don't want to overwrite any changes you might have made to package files.
it's a bit inconsistent mind because stylesheets work the same way except if you create a css file on disk then when you load the nodes inside umbraco - umbraco will take the file and put what it needs into the db. so if it did this for templates it would be way easier.
usync uses the core stuff because it is trying to always use the API when doing the imports, in many places usync does the standard import then some custom stuff on top to ensure changes that normally don't happen on a package do with usync - its just unfortunate in places that the package stuff does things like load loads of stuff you don't then need.
yes v7 is very nice - and v7.1 has a lot of the small issues ironed out - it's really cool to use now.
Derrr! Sorry I was being a complete numpty! Log4net IS the new error log system. Meh! Sometimes I think my ol' grey matter is going south. Thanks for the info. I had no idea you could change the logging level in the config. You learn something new every day :-)
I'll give it a try now.
Yes v7 is the way forward, I have worked a little on package development in v4/6 so it's going to be quite a learning curve doing it in angular. But i'm looking forward to the challenge.
I saw your change requests for 7.1 :-) There were lots of contributions and enough bumps have been smoothed over to make me feel confident enough to use it in a production project.
Bosh! found the offending file. My template code already had a CDATA element wrapping the CSS (Adobe Ilustrator SVG Export).
A quick question; How do I get uSync to rebuild the files if I manually delete them and restart the app? It doesnt seem to be rebuilding them, is it something to do with caches?
Template exception
Hi Kevin
I've recently installed uSync 1.5.8.2 on our hefty Umbraco 6.1.6 build.
I can get it to sync everything except templates. As soon as I turn them on Umbraco exceptions. It would seem that uSync has created a complete backup, but it's hard to say for sure as I have quite a lot of templates. The problem is the exception doesnt detail which template it's having a problem reading. See below...
2014-04-08 16:39:10,926 [28] ERROR Umbraco.Core.UmbracoApplicationBase - [Thread 47] An unhandled exception occurred
System.Xml.XmlException: Unexpected end of file has occurred. The following elements are not closed: Design, Template. Line 6, position 11.
at System.Xml.XmlTextReaderImpl.Throw(String res, String arg)
at System.Xml.XmlTextReaderImpl.ParseElementContent()
at System.Xml.XmlLoader.LoadNode(Boolean skipOverWhitespace)
at System.Xml.XmlLoader.LoadDocSequence(XmlDocument parentDoc)
at System.Xml.XmlDocument.Load(XmlReader reader)
at System.Xml.XmlDocument.Load(String filename)
at jumps.umbraco.usync.SyncTemplate.ReadFromDisk(String path)
at jumps.umbraco.usync.SyncTemplate.ReadFromDisk(String path)
at jumps.umbraco.usync.SyncTemplate.ReadFromDisk(String path)
at jumps.umbraco.usync.uSync.ReadAllFromDisk()
at jumps.umbraco.usync.uSync.RunSync()
at jumps.umbraco.usync.uSync.DoOnStart()
at Umbraco.Core.EnumerableExtensions.ForEach[TItem](IEnumerable`1 items, Action`1 action)
at Umbraco.Core.CoreBootManager.Complete(Action`1 afterComplete)
at Umbraco.Web.WebBootManager.Complete(Action`1 afterComplete)
Hi Martin,
Sorry it did that, i am trying to reduce the number of blocking errors in usync but it looks like one of the templates is missing a closing div or something and that is making the export upset - if you look in the log files (app_data/logs/umbracotracelog.txt) you should be able to see which of the templates was being processed when the error was thrown.
if that doesn't help turning up the logging in the log4net config (/config/log4net.config) from info to debug will give you a lot more information about what usync is doing.
if you find the template, then please do pass on the details, and i will look at getting usync to be a bit more resilient to the export/import of templates.
Kevin
Hi Kevin
That paste was from the tracelog, unfortunately with no indicator as to which file is misbehaving/
Does Umbraco store the actual template in the DB or just pointers to the template files?
Also I wouldve thought CDATA would be enough in your XML to prevent such errors, but it would appear in my case not to be enough. I seem to remember reading somewhere that some characters can still scupper CDATA sections.
M.
HI Martin
Yes sorry missed that - but changing to debug in log4net.config should then list the templates as it goes through them.
yes CDATA should do it but - unfortunately it's not usync that is generating the xml file, it's the core umbraco API. the same one used by packages. Its a bit of a pain because the export/import functions inside umbraco create this file, but as you point out they don't use the template content in the xml to update the template file
The template code is only used on first import - every other import all that is updated is the DB elements which is just the ID, Alias and Parent Id of the template.
For that reason templates are a bit painful to import - I have been looking in later versions at completely removing the dependency on the internal import /export functions for templates but at the moment (well until v7.1.0) you couldn't create the templates programatically with the core API because the Parent ID is internal to the core so you can't set it.
This is changing however and once I've tested that I think usync will move to its own template export/import that just does the IDs - until then the best i can do is fail the import and log it - it's a bit of a catch 22 because you might want to know the background process isn't working but then you don't want a YSOD all over your site because of it.
Kevin
Hi Kevin
How do I switch to log4net? I've never attempted it before.
Wow, i'm quite surprised at the import strategy on templates. You'd think as it's all file based Umbraco would just create keys in the DB regardless of first or subsequent imports! Oh well it is what it is and hopefully you'll have something better in place for 7.x going forward. I have to say i'm really looking forward to upgrading our main project to 7. I've done a test build 7.0.4, but I had a lot of issues upgrading the DB, but once I pushed passed the errors, it was great to see such enormous improvements in the UI.
We've all but dumped Courier 2 on our projects because it's just too unreliable, but I still need a robust way of pulling together a local build ready for production, so I'm hoping uSync will be a better fit.
M.
Hi
to change debug level go to /config/log4net.config and change the Priority value in the xml file from "Info" to "Debug"
so the top of the file will now look like
The way umbraco imports is a legacy thing really and to do with the fact that the import/export routines where orgininally written for package creation, so they export everything to be put in a package, and import it back in first time (but not subsequent times) because they don't want to overwrite any changes you might have made to package files.
it's a bit inconsistent mind because stylesheets work the same way except if you create a css file on disk then when you load the nodes inside umbraco - umbraco will take the file and put what it needs into the db. so if it did this for templates it would be way easier.
usync uses the core stuff because it is trying to always use the API when doing the imports, in many places usync does the standard import then some custom stuff on top to ensure changes that normally don't happen on a package do with usync - its just unfortunate in places that the package stuff does things like load loads of stuff you don't then need.
yes v7 is very nice - and v7.1 has a lot of the small issues ironed out - it's really cool to use now.
Hi Kevin
Derrr! Sorry I was being a complete numpty! Log4net IS the new error log system. Meh! Sometimes I think my ol' grey matter is going south. Thanks for the info. I had no idea you could change the logging level in the config. You learn something new every day :-)
I'll give it a try now.
Yes v7 is the way forward, I have worked a little on package development in v4/6 so it's going to be quite a learning curve doing it in angular. But i'm looking forward to the challenge.
I saw your change requests for 7.1 :-) There were lots of contributions and enough bumps have been smoothed over to make me feel confident enough to use it in a production project.
M.
Hi Kevin
Bosh! found the offending file. My template code already had a CDATA element wrapping the CSS (Adobe Ilustrator SVG Export).
A quick question; How do I get uSync to rebuild the files if I manually delete them and restart the app? It doesnt seem to be rebuilding them, is it something to do with caches?
M.
hi
if there is no uSync folder then usync will do a full export - so to reset just delete / rename the /usync folder
Kevin
Hi Kevin
Sorry, I did manage to work it out, I was leaving the folder empty.
On my production build I set write to false and read to true, but it's still writing out the structure on start-up, is that normal/correct?
M.
Sorry Kevin I should add i'm integrating uSync into an already established build, which already contains structure and content.
is working on a reply...