I'm sharing a test installation with remote team members. They are building their test sites, and I am building mine.
While trying to arrive at my ideal architecture I have had some false starts, creating templates, doc types and pages that I later deleted. I then used the same names when recreating the templates, doc types, or pages in a new structure (under a master page, master template, or master doctype). In doing so, I think I have gotten myself into trouble.
Should have have unpublished before deleting? Have I completely scrambled the database?
Here's what I'm experiencing. (and I apologize for not being able to give you a URL to visit.):
I publish my pages, but when I click the URL I get a 404. I've assigned each a Doctype and Template as described, below. When I use URL alias, a page shows up, with the content I'd like to actually display. In the one-column page, all seems fine, but in the two-column page, some properties don't display.
My current structure is:
CONTENT:
Sitename (will be the starting point for the domain, will not show in navigation)
Index (prefixed with an identifier) (this is a one-column page)
About (prefixed with an identifier) (this is an example of a two-column page)
TEMPLATES
MasterTemplate
OneColumnTemplate
TwoColumnTemplate
DOCTYPES
MasterDocType
HomePageDoctype (I made this to apply to the sitename node. Viewers do not see this page. Has no content)
OneColumnDoctype
TwoColumnDoctype
MY QUESTIONS as I fish for resolution (and I'll keep troubleshooting here, and will give any code or descriptions you want to see)
Is there an inherent problem with having the Doctypes one level lower in the tree than the templates that they relate to? Do I need to manually delete all the doctypes, templates and pages from the server and republish them? Why do I have to use an alias in order to get a page to display? Why are the properties of the two-column page not displaying?
Reinstalling is not an option, as the entire team is using this one install together.
1) Try "Republish entire site" on root "Content" node 2) Try unpublish site root node and then publish (rightclick, select childs) from site root node? 3) Are there any pages anywhere in the solution which uses a deleted doctype? If so, delete them. Empty trash. 4) Repeat from 1)
Not working?
Delete solution start over - sounds like it's almost empty :-)
Yes, I was just starting. I can check with my colleagues to see how far along they are as well. I have built the complete site in HTML, built proof of concept on a single installation locally, and now I'm testing how to handle multi-site installation on the test server.
I will try your suggestions and report back. I don't think I've used a deleted doctype anywhere, but I'll check for that.
I'm back again. I've been rebuilding the solution from scratch.
So far I've only created my index (single column) page, and while the page is showing without a 404 (improvement!), the single property that I added to the template is not showing... unless I create an Umbraco URL Alias in which case it shows.
Here's my structure. Can you tell me if anything here is bad practice?
Content
siteRoot (using siteRoot doctype and either siteRoot or siteMaster template.. same result stated above)
siteIndex (using siteIndex doctype and siteIndex template)
property: indexLinks (does not display unless there is an Alias)
Templates
siteMaster <asp:content ContentPlaceHolderDefault ... which contains <asp:ContentPlaceHolder ID="ContentOverall"...
siteIndex <asp:content ContentPlaceHolderId="ContentOverall"... with site markup and also contains <umbraco:Item field="indexLinks"...
Document Types
siteMaster (based on Master Document Type template)
siteRoot (adds no new properties, but I allowed both siteMaster and siteRoot templates for testing purposes)
siteIndex (allows siteIndex template, adds one property: indexLinks, which is populated in the content page)
The reason I have not perfectly mirrored the structure is that I want the site root to function as a redirect to the home page. Do the Doctypes need to nest? The templates don't need to nest for functional purposes in the markup, but are there hidden rules that dictated nested templates? I want to avoid having any of the nodes refer to the Master Document Type in order to keep it out of the mix.
Advice for others who follow after: It looks like what was needed was a lot of reloading and republishing and refreshing until the Database finally caught up with me. 24 Hours later I'm able to view my content without an alias, and I haven't changed anything.
I have to wonder if there is something programmatic that can be done about this lag. While creating sites, people are likely to do a lot of creating, deleting, false starts, fits and stops. And at any point in this process, as long as all their t's are crossed, they should be able to view the site as it is in its present state.
It would seem that the most troublesome scenarios are when one creates a document type that automatically (but accidentially) generates a matching template (perhaps at the top level of the site, while the intended template is nested deeper). One then deletes the accidental template, and assigns the correct one to the document type and the content page. At this point, due to the accidental template creation, one must reload all the nodes and republish the full site (or so it seems.)
If this could be remedied so that it is never a problem, I'd be a happier camper. One suggestion would be to find a way to prevent accidental creation of the template. In my browser, as soon as you start typing, there is a drop-down list obstructing the checkbox. Hitting the "enter" key to select a name for the document type (preserved in memory from earlier attempts) sometimes presses the button for the "Create" form. I would prefer that the "create matching template" box were unchecked by default. Or perhaps the checkbox should be ABOVE the two textboxes, so the drop-down will not be in the way? Anyway, as it is now, I fumble around every time I create a document type for which I do not want to automatically generate a template.
So let the creator beware... maybe uncheck the box BEFORE you fill in a name for your doctype?
I'm still trying to figure out why I need a URL alias in order for the properties of my index page to display.
I don't want to proceed if I'm doing something fundamentally wrong. Is there anything inadvisable about the structure I outlined 5 days ago in my second description?
I've rebuilt the site node from scratch three times just to make sure I didn't have any funky leftovers hanging out.
Many thanks for suggestions, questions, guidance, or ideas.
We started over again on a fresh test site, different database, etc. Not experiencing that problem. I suspect there was a setting somewhere leftover from previous testing that was affecting things.
Site editing - deleting and recreating nodes
Hi,
I'm sharing a test installation with remote team members. They are building their test sites, and I am building mine.
While trying to arrive at my ideal architecture I have had some false starts, creating templates, doc types and pages that I later deleted. I then used the same names when recreating the templates, doc types, or pages in a new structure (under a master page, master template, or master doctype). In doing so, I think I have gotten myself into trouble.
Should have have unpublished before deleting? Have I completely scrambled the database?
Here's what I'm experiencing. (and I apologize for not being able to give you a URL to visit.):
I publish my pages, but when I click the URL I get a 404. I've assigned each a Doctype and Template as described, below. When I use URL alias, a page shows up, with the content I'd like to actually display. In the one-column page, all seems fine, but in the two-column page, some properties don't display.
My current structure is:
CONTENT:
Sitename (will be the starting point for the domain, will not show in navigation)
Index (prefixed with an identifier) (this is a one-column page)
About (prefixed with an identifier) (this is an example of a two-column page)
TEMPLATES
MasterTemplate
OneColumnTemplate
TwoColumnTemplate
DOCTYPES
MasterDocType
HomePageDoctype (I made this to apply to the sitename node. Viewers do not see this page. Has no content)
OneColumnDoctype
TwoColumnDoctype
MY QUESTIONS as I fish for resolution (and I'll keep troubleshooting here, and will give any code or descriptions you want to see)
Is there an inherent problem with having the Doctypes one level lower in the tree than the templates that they relate to? Do I need to manually delete all the doctypes, templates and pages from the server and republish them? Why do I have to use an alias in order to get a page to display? Why are the properties of the two-column page not displaying?
Reinstalling is not an option, as the entire team is using this one install together.
Thanks for any help.
D
UPDATE: I got the 2 column properties all to display. So I'm focusing on why I need an alias.
Another Update: I've double-triple checked and every page has a template. Still fishing.
Hi Diana,
1) Try "Republish entire site" on root "Content" node
2) Try unpublish site root node and then publish (rightclick, select childs) from site root node?
3) Are there any pages anywhere in the solution which uses a deleted doctype? If so, delete them. Empty trash.
4) Repeat from 1)
Not working?
Delete solution start over - sounds like it's almost empty :-)
/Best
Jesper
Thanks, Jesper!
Yes, I was just starting. I can check with my colleagues to see how far along they are as well. I have built the complete site in HTML, built proof of concept on a single installation locally, and now I'm testing how to handle multi-site installation on the test server.
I will try your suggestions and report back. I don't think I've used a deleted doctype anywhere, but I'll check for that.
Again, thanks for the input.
D
I'm back again. I've been rebuilding the solution from scratch.
So far I've only created my index (single column) page, and while the page is showing without a 404 (improvement!), the single property that I added to the template is not showing... unless I create an Umbraco URL Alias in which case it shows.
Here's my structure. Can you tell me if anything here is bad practice?
Content
siteRoot (using siteRoot doctype and either siteRoot or siteMaster template.. same result stated above)
siteIndex (using siteIndex doctype and siteIndex template)
property: indexLinks (does not display unless there is an Alias)
Templates
siteMaster <asp:content ContentPlaceHolderDefault ... which contains <asp:ContentPlaceHolder ID="ContentOverall"...
siteRoot <asp:content ContentPlaceHolderId="ContentOverall"...
siteIndex <asp:content ContentPlaceHolderId="ContentOverall"... with site markup and also contains <umbraco:Item field="indexLinks"...
Document Types
siteMaster (based on Master Document Type template)
siteRoot (adds no new properties, but I allowed both siteMaster and siteRoot templates for testing purposes)
siteIndex (allows siteIndex template, adds one property: indexLinks, which is populated in the content page)
The reason I have not perfectly mirrored the structure is that I want the site root to function as a redirect to the home page. Do the Doctypes need to nest? The templates don't need to nest for functional purposes in the markup, but are there hidden rules that dictated nested templates? I want to avoid having any of the nodes refer to the Master Document Type in order to keep it out of the mix.
Thanks for any further ideas.
All the best,
Diane
Advice for others who follow after: It looks like what was needed was a lot of reloading and republishing and refreshing until the Database finally caught up with me. 24 Hours later I'm able to view my content without an alias, and I haven't changed anything.
I have to wonder if there is something programmatic that can be done about this lag. While creating sites, people are likely to do a lot of creating, deleting, false starts, fits and stops. And at any point in this process, as long as all their t's are crossed, they should be able to view the site as it is in its present state.
It would seem that the most troublesome scenarios are when one creates a document type that automatically (but accidentially) generates a matching template (perhaps at the top level of the site, while the intended template is nested deeper). One then deletes the accidental template, and assigns the correct one to the document type and the content page. At this point, due to the accidental template creation, one must reload all the nodes and republish the full site (or so it seems.)
If this could be remedied so that it is never a problem, I'd be a happier camper. One suggestion would be to find a way to prevent accidental creation of the template. In my browser, as soon as you start typing, there is a drop-down list obstructing the checkbox. Hitting the "enter" key to select a name for the document type (preserved in memory from earlier attempts) sometimes presses the button for the "Create" form. I would prefer that the "create matching template" box were unchecked by default. Or perhaps the checkbox should be ABOVE the two textboxes, so the drop-down will not be in the way? Anyway, as it is now, I fumble around every time I create a document type for which I do not want to automatically generate a template.
So let the creator beware... maybe uncheck the box BEFORE you fill in a name for your doctype?
Back again. I take back my conclusions. I have not yet gotten the node to display the property. And as far as I can tell, all my T's are crossed.
Starting from scratch again.
Last try at a :::bump:::
Jesper (or anybody),
I'm still trying to figure out why I need a URL alias in order for the properties of my index page to display.
I don't want to proceed if I'm doing something fundamentally wrong. Is there anything inadvisable about the structure I outlined 5 days ago in my second description?
I've rebuilt the site node from scratch three times just to make sure I didn't have any funky leftovers hanging out.
Many thanks for suggestions, questions, guidance, or ideas.
Diane
Conclusion/Solution for any who follow:
We started over again on a fresh test site, different database, etc. Not experiencing that problem. I suspect there was a setting somewhere leftover from previous testing that was affecting things.
is working on a reply...