Just yesterday I was finally given clearance to install Umbraco Courier to a client's site (they had to buy the license, then actually tell me that I was allowed to, since I am only contracted to them through my employer), and I completed the installation without issue. However, today I attempted to actually transfer the content pages from production to development (an initial transfer so as to avoid any risk to the production environment), and though the transfer went off without a hitch, I have run into a few issues.
Namely, this:
Server Error in '/' Application.
Object reference not set to an instance of an object.
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.NullReferenceException: Object reference not set to an instance of an object.
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:
[NullReferenceException: Object reference not set to an instance of an object.]
umbraco.controls.ContentControl.addControlNew(Property p, TabPage tp, String Caption) +93
umbraco.controls.ContentControl.CreateChildControls() +833
System.Web.UI.Control.EnsureChildControls() +181
umbraco.controls.ContentControl.OnInit(EventArgs e) +122
System.Web.UI.Control.InitRecursive(Control namingContainer) +132
System.Web.UI.Control.AddedControl(Control control, Int32 index) +276
umbraco.cms.presentation.editContent.OnInit(EventArgs e) +1004
System.Web.UI.Control.InitRecursive(Control namingContainer) +132
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1969
But the error alone isn't too helpful, is it? What I did was, I selected Courier for the base home page, which each other page is a child of, and told it to transfer without dependencies. The client's website is large and I was mindful of the Courier manual's recommendation to avoid large transfers (it specifies 300 nodes or more), hence sending over the content by itself rather than with its dependencies.
Upon review, though, the transfer included more than I expected, 20 files and 328 items, so this could well be the issue. Either way, I would like confirmation in case the problem is elsewhere and not so easily avoided in the future, and I have already recommended that the client restore the development environment to its state prior to installation (and usage) of Courier.
Further details are that the error page in question does not appear everywhere; it seems to pick and choose at random. I feel that there must be a pattern, but so far I have been unable to identify it. The majority of pages seem to be fine, though. Additionally, some pages have been duplicated, with one copy giving this error and the other working as normal, but the error is not limited to this scenario of duplication.
I found two more things to be particularly odd: first of all, that the Courier section contains a Deploy folder instead of a Revisions folder, though this could potentially be explained by the transition from unlicensed to licensed (my tests being done locally on an unlicensed copy, without any issues, hence my advice to move forward with Courier).
The second is that in my tests (again, an unlicensed version of Courier), I found that the first time that I made a transfer resulted in complete structure duplication for content pages (notably, though, not for stylesheets and the like) and required the old material be deleted to leave only that provided by Courier. I have long since mentally justified this as Courier understanding that you can have several pages with the same name, so it should not necessarily overwrite content pages that it itself had not sent, but this did not happen in my experience today. Instead, the deployment initially looked like it had gone perfectly and overwritten the files on development instead of treating them as foreign to the task at hand.
Neither of these things are necessarily relevant, but I am at a loss as to how to explain the necessity of actually using the backup, and how to avoid such a necessity in general use of Courier in the future, and it is my sincere hope that somebody will be able to shed light on this issue.
Well, that's just...that's just great. I solved the problem by republishing the site, something I hadn't even considered as a solution. I can now view and edit the pages as per normal.
Those Razor Script errors I mentioned are still there, but those are potentially a completely different problem. Still, in the interest of avoid this in the future, if there's an explanation for all that happened, I would like to hear it.
Now I'm going to go cry in a corner for all the stress this has caused me when the solution was so simple.
Well, to track down what is going on with those random pages not working, you have to look at the data types used.
Is there a specific data type used on those failing documents? I would suspect a custom data type using umbraco content in a specific way that makes your content pages fail, as Courier uses a custom datalayer to work with data to get around umbracos event model, it might conflict with something that depends on events being triggered, but really just guessing here.
For the Razor Script errors, I have no idea, they werent there before? no new dlls or other differences between the 2 environments?
Ah, very sorry, Per; I completely forgot about this thread as soon as I was able to get back to work on the project.
From what I could tell, there was nothing specific to link the failing pages together while excluding the functional ones, as it varied between pages with the same template and document types. My current working theory is that the offenders were pages that were different between production and development, and thus required being published before Umbraco could properly find them while the old pages were displayed until that very event. I do not know all of the details of course, but it makes a sort of sense to me that I cannot completely explain, though I hesitate to attempt to replicate it.
The Razor Script errors were a result of script (that I did not write) relying on locating content pages by ID, which varied between development and production. Why that ever seemed like a good idea escapes me.
Issue With Transferring Content
Hello,
Just yesterday I was finally given clearance to install Umbraco Courier to a client's site (they had to buy the license, then actually tell me that I was allowed to, since I am only contracted to them through my employer), and I completed the installation without issue. However, today I attempted to actually transfer the content pages from production to development (an initial transfer so as to avoid any risk to the production environment), and though the transfer went off without a hitch, I have run into a few issues.
Namely, this:
Server Error in '/' Application.
Object reference not set to an instance of an object.
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.NullReferenceException: Object reference not set to an instance of an object.
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:
But the error alone isn't too helpful, is it? What I did was, I selected Courier for the base home page, which each other page is a child of, and told it to transfer without dependencies. The client's website is large and I was mindful of the Courier manual's recommendation to avoid large transfers (it specifies 300 nodes or more), hence sending over the content by itself rather than with its dependencies.
Upon review, though, the transfer included more than I expected, 20 files and 328 items, so this could well be the issue. Either way, I would like confirmation in case the problem is elsewhere and not so easily avoided in the future, and I have already recommended that the client restore the development environment to its state prior to installation (and usage) of Courier.
Further details are that the error page in question does not appear everywhere; it seems to pick and choose at random. I feel that there must be a pattern, but so far I have been unable to identify it. The majority of pages seem to be fine, though. Additionally, some pages have been duplicated, with one copy giving this error and the other working as normal, but the error is not limited to this scenario of duplication.
I found two more things to be particularly odd: first of all, that the Courier section contains a Deploy folder instead of a Revisions folder, though this could potentially be explained by the transition from unlicensed to licensed (my tests being done locally on an unlicensed copy, without any issues, hence my advice to move forward with Courier).
The second is that in my tests (again, an unlicensed version of Courier), I found that the first time that I made a transfer resulted in complete structure duplication for content pages (notably, though, not for stylesheets and the like) and required the old material be deleted to leave only that provided by Courier. I have long since mentally justified this as Courier understanding that you can have several pages with the same name, so it should not necessarily overwrite content pages that it itself had not sent, but this did not happen in my experience today. Instead, the deployment initially looked like it had gone perfectly and overwritten the files on development instead of treating them as foreign to the task at hand.
Neither of these things are necessarily relevant, but I am at a loss as to how to explain the necessity of actually using the backup, and how to avoid such a necessity in general use of Courier in the future, and it is my sincere hope that somebody will be able to shed light on this issue.
Thank you for your help,
-Matt
Further information, I have noticed that the razor scripts no long function, with a couple of errors:
Error loading Razor Script LatestVideoList.cshtml
Unable to cast object of type 'umbraco.MacroEngines.DynamicNull' to type 'System.IConvertible'.
Error loading Razor Script LatestPressReleaseList.cshtml
Cannot invoke a non-delegate type
The website itself is still up, only Umbraco seems to be having trouble with this.
Well, that's just...that's just great. I solved the problem by republishing the site, something I hadn't even considered as a solution. I can now view and edit the pages as per normal.
Those Razor Script errors I mentioned are still there, but those are potentially a completely different problem. Still, in the interest of avoid this in the future, if there's an explanation for all that happened, I would like to hear it.
Now I'm going to go cry in a corner for all the stress this has caused me when the solution was so simple.
Hi matthew
Well, to track down what is going on with those random pages not working, you have to look at the data types used.
Is there a specific data type used on those failing documents? I would suspect a custom data type using umbraco content in a specific way that makes your content pages fail, as Courier uses a custom datalayer to work with data to get around umbracos event model, it might conflict with something that depends on events being triggered, but really just guessing here.
For the Razor Script errors, I have no idea, they werent there before? no new dlls or other differences between the 2 environments?
Ah, very sorry, Per; I completely forgot about this thread as soon as I was able to get back to work on the project.
From what I could tell, there was nothing specific to link the failing pages together while excluding the functional ones, as it varied between pages with the same template and document types. My current working theory is that the offenders were pages that were different between production and development, and thus required being published before Umbraco could properly find them while the old pages were displayed until that very event. I do not know all of the details of course, but it makes a sort of sense to me that I cannot completely explain, though I hesitate to attempt to replicate it.
The Razor Script errors were a result of script (that I did not write) relying on locating content pages by ID, which varied between development and production. Why that ever seemed like a good idea escapes me.
is working on a reply...