I've inherited a Sitecore project and added a new alias to a set of existing aliases on an item within the content tree.
However, although I can visit the older aliases any of my new aliases seem not to work and lead to a 404.
I've tried publishing the content items and even System/Aliases however they still refuse to work.
Am I missing something obvious?
Several things could be preventing your aliases from working, some of which depend on the setup of your system:
Verify that your aliases were published. To do this, switch over to your Web DB and check to see if the aliases that you configured appear, as expected. If they are not published, be sure to run a publish on the Aliases folder (I suggest a Republish, just to be safe).
If after that your aliases are not working and are still not published, try running a full site Republish.
If they still won't publish, move on to number 3, below
If your aliases your aliases are not working and are published, try rebuilding the Link Database.
If your aliases are still not working, move on to numbers 2 and 4, below
Ensure that each alias that you defined is unique. Note that for a multi-site solution, being unique for the context site is not enough - if you have the alias defined for one of the sites and try to define it for the other it will not work - as the alias cannot be used differently for each site.
Note that this is the default behavior of Sitecore's AliasResolver
If necessary, you can customize the AliasResolver to allow you to specify a separate alias folder for each site, following this tutorial by Yogesh Patel.
(skip this if you completed step 1 and were able to publish your aliases successfully) Special Access Rights/Permissions are required in order to configure Sitecore aliases. I highly doubt that this is the issue, as you were clearly able to create alias items, but I am a fan of covering the base-cases first, so I would verify all the same.
If you do find that you are missing the necessary permissions and are trying to figure out how to configure them/if you have trouble finding what permissions you need then you should take a look at this article, by John West.
Also unlikely, but possible, is that redirects/rewrites were configured to send you to the 404 page from the URLs you set as aliases (it could be a RegEx that redirects all of the URLs that you tried to provide as aliases). Start by checking out your config files and/or IIS for Rewrites and Redirects. If you do not see anything, then check for redirects.
If redirects are your issue, then the Redirect Module is likely to be the culprit. Check if it is installed and configured to redirect your aliases to 404 pages
If the Redirect Module is not configured, check for custom redirection in your code
Hopefully this helps. Good luck and happy coding! :)
After checking the points raised by Zachary Kniebel I finally figured it was down to the scope of the items and how URL are generated.
For example we have:
Home/
Holidays/
Some Item
Now the alias could be Toads on Some Item. So I assumed the following URL would work:
http://www.example.com/holidays/some-item
http://www.example.com/holidays/toads
However, because aliases are system wide it dawned on me that really the alias was:
http://www.example.com/toads
This means in order to get the structure I wanted I had to create the alias Holidays/Toads instead of just Toads, replicating the tree structure as needed.
When I did this the aliases started working as expected.
Related
I have multiple sites architecture. Like this one
sitecore/content/site1
sitecore/content/site2
For each item of site2 referenced in site1 I get the following URL:
www.site1.com/sitecore/content/site2/item
instead of
www.site2.com/item
I've debugged Sitecore.Sites.DefaultItemSiteResolver and found, that the site can be only resolved only if it has "Enable Preview" site property set to true:
But now, after setting it to true, I have another problem, the page resolving now works also in the preview (which is not the desired behavior, I want only the "webiste" site to be resolved there). It even ignores the "Preview.ResolveSite" setting, which is set to false.
What am I doing wrong? How to enable site resolving for published sites but not for the preview?
There are several settings in Sitecore.config that help to configure proper site resolving logic in multisite Sitecore solutions:
Rendering.SiteResolving — enables site resolving, so cross-site links can be rendered with correct hostname, language, and virtual folder.
Rendering.SiteResolvingMatchCurrentSite — item location is taken into consideration when a cross-site link is built. All items under a certain site root will be resolved in the context of that root.
Rendering.SiteResolvingMatchCurrentLanguage — when true, context language is taken into consideration when a cross-site link is built.
It is recommended to keep the Rendering.SiteResolving setting value at true for any multisite solution in order to ensure that cross-site links are built with the correct parameters. In this case, the Experience Editor and Preview mode are opened in the context of the site defined in the Preview.DefaultSite setting, if no other site can be resolved.
To make sure that items are opened in context of correct site, you must set the Rendering.SiteResolvingMatchCurrentSite setting to true.
I have a few related selects that work perfectly on a testing server with very loose security (basically just a simple default install of CF 10).
I have tried to implement the CF 10 lockdown guide on the production server and all seems well, except that related select don't work. That is, the first select in the chain doesn't populate and therefore, none of the related selects populate either.
I even recreated Ben Forta's art media example: perfect on the testing server, no triggering in production.
All other CFC functions seem to work: SELECT and INSERT queries are just fine. Only CFSELECTs with bindings are hosed. I pretty sure that the problem is a server configuration. The same pages worked just fine on our old CF 9 box. Any ideas would be helpful.
My advice to you would be to NOT use cfselect or any other UI stuff in ColdFsuion - It only causes more headaches than it gets rid of.
That being said, if you followed the lockdown guide, you should have limited access to the CFIDE directory - which is needed for any of the ColdFusion UI stuff. There is an option in CF Admin to use a 'custom' path for the scripts ColdFusion uses - it is on the main Settings page. Set this value and create a virtual directory in IIS with the same name pointing to the {cfroot}CFIDE/scripts directory.
How do you change the default database used when loggin in to the backend of Sitecore?
I an solution i am currently working on, whenever a user logs in to the backend it defults to the web database and not the master as it should.
i have checked the sites definition in the web.config, but no luck - it is set to master.
Where else could i look?
Unfortunately there is a number of ways this could be configured. Without actually seeing your configuration files, it is difficult to point out which.
I can tell you this however. The likely cause would either be:
Your site definition for the "shell" site. By default it has a content="master" attribute - by changing this, you would (likely) change the database the users work in. I say "likely", since it isn't really the recommended approach to my knowledge.
The same setting could also be set in a .config include file, so it may not be in the main web.config file itself.
For a reference to how these (web.config include files) work; check out http://www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2011/05/All-About-web-config-Include-Files-with-the-Sitecore-ASPNET-CMS.aspx
I have had WFFM running on a Sitecore instance for a while, but it has recently stopped working. When I go to "Form Designer" on an existing form, I get the standard Sitecore "The requested document was not found" page.
Requested URL: /applications/modules/web
User Name: sitecore\admin
Site Name: shell
If the page you are trying to display exists, please check that an
appropriate prefix has been added to the IgnoreUrlPrefixes setting in
the web.config.
Note that the requested URL is stated as /applications/modules/web instead of /applications/modules/web forms for marketers.
A lot of development has occurred on this site recently, so I'm not sure when exactly this started happening.
Additional: info:
Folder and file permissions are correct.
I've tried reinstalling the WFFM package, and made sure that all the files are in place.
Several processors have been added to the HttpBeginRequest pipeline, but I removed them all to test if they were the cause - they weren't.
I haven't upgraded Sitecore since WFFM was working and the version is correct.
No errors are logged
EDIT
This also seems to be affecting the Sitecore Security Editor:
Requested URL: /appl
User Name: sitecore\admin
Site Name: shell
If the page you are trying to display exists, please check that an
appropriate prefix has been added to the IgnoreUrlPrefixes setting in
the web.config.
EDIT 2
Further investigation with this is making me think it is related to the Requested URL. I originally thought the the "Not found" page was displaying the requested url incorrectly. However, if I attempt to goto mysite.com/sitecore/shell/applications/fake folder with spaces/fake page with spaces I get this error message:
Requested URL: /applications/fake folder with spaces/fake page with
spaces
User Name: sitecore\admin
Site Name: shell
If the page you are trying to display exists, please check that an
appropriate prefix has been added to the IgnoreUrlPrefixes setting in
the web.config.
As you can see the Requested Url is correct in the error message. So in relation to my problem, I think maybe Sitecore is requesting the wrong URL in the first place.
Additionally if I go to the go the following url by typing directly into the browser, then the Security Editor opens as expected:
mysite.com/sitecore/shell/Applications/Security/User-Editor
This is quite old now but I thought I'd provide an update for anyone else who encounters the problem.
Unfortunately, Sitecore support weren't able to help beyond pointing out that setting the addAspxExtension attribute to 'true' in the link provider seemed to solve the problem. This may have been acceptable except that extensionless URLs were important to the customer.
In the end I had to amend my link provider so that addAspxExtension is set to 'true' in the web config, and then I set it to false inside the GetItemUrl method for specified sites only.
So now whenever the context site is 'Shell' or 'Admin' etc, the extensions are added by default, but switched off in my main website.
Of course, this is a work around. I still don't know how to actually fix the problem
So the first thing that I am going to tell you is that I suspect that there is something wrong with your site declaration for Sitecore Modules. In your web.config, there's a site declaration for "modules_shell" and "modules_website". Those are where the code files that run the modules are usually located... a shell folder to run the parts that run in the Sitecore shell and a web folder to run the part that is accessed by the externally facing site. Please check your site declarations (and the form.config file) to make sure that you're not in live mode or something like that. I would definitely say that this is where you should start looking.
The next thing is to say that your comments about Sitecore not serving a url in the /sitecore/shell directory is really not surprising. Sitecore processes all requests unless you specifically tell it to ignore requests (like setting it in the IgnoreUrlPrefixes in web.config), it's going to try processing it. Like going to /sitecore/shell/applications gives me a layout error because it doesn't have anything set to handle that request. Now your error suggests that there is something wrong with Site declarations.. however, even if they were all right, it still wouldn't work.
I have 50 different websites that use the same layout and code base, but mostly non-overlapping data (regional support sites, not link farm). Is there a way to have a single installation of the code and run all 50 at the same time?
When I have a bug to fix (or deploy new feature), I want to deploy ONE time + 1 restart and be done with it.
Also:
Code needs to know what domain the request is coming to so the appropriate data is displayed.
The Sites framework comes to mind.
Apart from that we have Django running for multiple sites by symlinking Django to various docroots. Works like a charm, too.
I can see two quite distinct ways to do this:
Use one database and the sites framework. Every post/picture/whatever model is connected to a Site and you always filter on Site. This requires a separate settings file for every database.
Use one database for each and every site. This allows different users for every site, but requires duplication of everything that is stored in the database. It also requires a separate settings file pointing to the correct database.
Either way, you do not duplicate any code, only data.
--
If you need to do site-specific, or post-specific changes to ie. a template, you should read up on how Django loads templates. It allows you to specify a list, ie ["story_%d.html", "story_site_%d.html", "story.html"] and django will look for the templates in that order.
I just ran into this and ended up using a custom middleware class that:
Fetch the HTTP_HOST
Clean the HTTP_HOST (remove www, ports, etc.)
Look up domain in a Website table that's tied to each account.
Set the account instance on the HTTPRequest object.
The throughout my view code I do lookups based on the account stored in the HTTPRequest objects.
Hope that helps someone in the future.