Newly created items get Link to document value of #
Hi,
Umbraco v
4.5.2 (Assembly version: 1.0.3891.20719)
ASP.NET 4.0
Windows Web Server 2008 R2 and IIS 7
I'm running two web nodes with DFS replication between the nodes. The Umbraco back office is only accessible from one server.
Problem:
Creating and publishing new items in the content tree give the new items a Link to Document value of # in the back office. The newly published content is not accessible off the server that we use to access the back office (results in a 404), but is accessible off the other server.
The content type doesn't matter, all new items get a value of # when published.
I'm seeing two types of error in the umbraco log:
logHeader logComment NotFound errorpage.aspx (from '') -- this is a 404 for hitting a specific page
logHeader logComment Error At /learn/videos/rss.ashx (Referred by: ): -- this is an internal rewrite rule failing
Recent changes:
The only recent change to the site was adding custom 404 error messages which I adjusted the umbracoSettings.config for:
<errors> <!-- the id of the page that should be shown if the page is not found --> <!-- <errorPage culture="default">1</errorPage>--> <!-- <errorPage culture="en-US">200</errorPage>--> <error404> <errorPage culture="default">22010</errorPage> </error404> </errors>
I've tried backing out these changes and am still hitting the same problem.
Troubleshooting steps:
I tried republishing the site from the main content node, that didnt' work.
I tried republishing the Root node and all childern, that resulted in a time out (we have 2500+ pages).
I deleted the indexes on the primary node (which we use for back office) and recycled the app pools on both machinces, and that didn't work.
Problem was we were locking down all back office URLs to use HTTPS. For some reason the internal calls Umbraco makes must go over port 80 (HTTP).
Disabling of our automatic rewrite rule for anything in the back office (^umbraco/(.*)) followed by republishing all nodes from the root fixed this issue.
Newly created items get Link to document value of #
Hi,
Umbraco v 4.5.2 (Assembly version: 1.0.3891.20719)
ASP.NET 4.0
Windows Web Server 2008 R2 and IIS 7
I'm running two web nodes with DFS replication between the nodes. The Umbraco back office is only accessible from one server.
Problem:
Creating and publishing new items in the content tree give the new items a Link to Document value of # in the back office. The newly published content is not accessible off the server that we use to access the back office (results in a 404), but is accessible off the other server.
The content type doesn't matter, all new items get a value of # when published.
I'm seeing two types of error in the umbraco log:
logHeader logComment
NotFound errorpage.aspx (from '') -- this is a 404 for hitting a specific page
logHeader logComment
Error At /learn/videos/rss.ashx (Referred by: ): -- this is an internal rewrite rule failing
Recent changes:
The only recent change to the site was adding custom 404 error messages which I adjusted the umbracoSettings.config for:
<errors>
<!-- the id of the page that should be shown if the page is not found -->
<!-- <errorPage culture="default">1</errorPage>-->
<!-- <errorPage culture="en-US">200</errorPage>-->
<error404>
<errorPage culture="default">22010</errorPage>
</error404>
</errors>
I've tried backing out these changes and am still hitting the same problem.
Troubleshooting steps:
I tried republishing the site from the main content node, that didnt' work.
I tried republishing the Root node and all childern, that resulted in a time out (we have 2500+ pages).
I deleted the indexes on the primary node (which we use for back office) and recycled the app pools on both machinces, and that didn't work.
Any ideas would be greatly appreciated. Thanks!
Fixed!
Problem was we were locking down all back office URLs to use HTTPS. For some reason the internal calls Umbraco makes must go over port 80 (HTTP).
Disabling of our automatic rewrite rule for anything in the back office (^umbraco/(.*)) followed by republishing all nodes from the root fixed this issue.
is working on a reply...