I have done the following:
installed a clean Sitecore 7.5 instance
added the relevant asp.net web forms controls and pages to support the site
imported and published a content tree from an old application
Visiting the base site url yields a YSOD with the error message:
Could not find configuration node: contactRepository
Now I understand what this means - there's an expected configuration section that is missing. Adding an empty element contactRepository yields an expected message that this section is not defined.
What is contactRepository, what is its associated configuration section type, what is it for and what values should be specified in it? Alternatively, how can I turn off whatever demands this section to be present?
edit #1:
In the Sitecore.Analytics.config file in the node there are the following two lines:
<!--This configuration node is obsolete and will be removed in a future version of Sitecore. Use "contactRepository" node to get access to Contact repository-->
<contactRepository ref="contactRepository"/>
The comment is total gibberish. Which node? 'Use' how? 'get access' in what sense? How is this different to what's there?
replacing with an empty <contactRepository> without the ref attribute, commenting out this node, both nodes, and the whole tracking node makes no difference to the application's behaviour.
Looking at my local Sitecore 7.5 setup the Contact Repository settings should be in your Sitecore.Analytics.config.
The contacts repository settings relate to the new xDB stuff.
Please ensure you have the correct Sitecore.Analytics config files for 7.5.
There should be around 15 config files with new settings for xDB.
Please read this blog post for more information on the new Analytics setup.
https://www.sitecore.net/learn/blogs/technical-blogs/getting-to-know-sitecore/posts/2014/10/introducing-the-sitecore-analytics-index
Related
How can i set up multi portal website in sulu cms?
Example: I will have one admin panel from that i will manage content of site like
a.com, b.com, c.com...
I try by make copy of file
app/Resources/webspaces/example.com.xml
and make file lilke app/Resources/webspaces/one.com.xml
And in example.com.xml i also add another portal tag in portals but had no luck...
but in admin panel left side i see just one site example.com
How can i do that? Is there any documentation? Any link?
Thanks!
Multiple portals within the same webspace are not visible in the Administration UI, what you want are multiple webspaces. Just create a second XML file as described in our documentation, and make sure you have different URLs setup and both webspaces have a different value in their key tag. Afterwards you have to execute the bin/console sulu:document:init command once more to initialize some nodes.
Maybe also check the logs in var/logs for any errors and warnings, because if you have an error in your webspace configuration file, the new webspace will not show up in the admin UI.
Another thing that could go wrong is that you are missing the permissions to see the new webspace (that usually happens when you create a new webspace after you've executed the command mentioned above). In that case you have to navigate to Settings -> User roles -> Your userrole, and add the missing permissions in the shown matrix.
I already made pipeline. Which is working fine. Suddenly it give error like
2015-12-18 02:39:08.091 GMT] ERROR system.core ISH-CORE-2368 Sites-SiteGenesis-Site core Storefront [uuid] [request-id]-0-00 [timestamp] "Error executing pipeline: Hello com.demandware.beehive.core.capi.pipeline.PipelineExecutionException:Pipeline not found (Hello) for current domain (Sites-SiteGenesis-Site)"
Does anybody know how to solve this?
In the event that your pipeline can not be found for the selected domain, please go trough and verify all of the following:
Double check Pipeline-Node naming
Pipeline URLs are generated by their name and your desired entry node, in this scenario, I would expect a file named Hello.xml in you cartridge's pipeline directory, and a start node named Start, would be accessed via {instanceURL}/on/demandware.store/Sites-mySite-Site/Hello-Start
Try and force upload of your cartridges
Occasionally the files on the server will not be updated correctly when a save is made; to force an update, right click your project, click Demandware > Upload Cartridges
Check your Cartridge Path
If you are using a shared instance, or your instance is re-provisioned, you may need to check your cartridge path to be sure your custom cartridge(s) are still there.
Check your Code Versions
Occasionally you may increment / change your code version - if you do, make sure that the path you select in Studio is the one that you have selected in Business Manager.
Tech Support
Should you still have issues following the four steps above, please file a support ticket and the tech-support team will be able to provide you with more assistance.
I'm facing a problem, and don't know if anybody has solved this issue.
I'm using Tridion webdav (Tridion 2011 SP1 HR1) to insert structured content (folders + binary files) into a publication.
All goes well when the folder doesn't exist, but if the folder exist, then an error appear:
You do not have permission to access this Web Folder location
Watching the log files, the problem is that Tridion tries to create a new folder when I drag & drop an existing folder, and rename to the folder title, giving an error:
Name must be unique for items of type: Folder/Virtual Folder within this Folder and its BluePrint context.
I tried using Events to avoid saving the folder when it exists (throwing an exception in the initiated phase), but the permission error appears when updating the content inside the folder.
Has anyone tried to do something alike?
Has anyone any sugestion I can try?
Thank you all in advance.
This has nothing to do with Tridion as you are using Windows Explorer to access WebDAV, so if anything it's the Explorer who is to blame for sending wrong requests, but if you will take a look at WebDAV sprcification here: http://www.webdav.org/specs/rfc4918.html, you can see all the possible calls under chapter 9.
Tridion Folders are treated as collections, so there's a MKCOL call to create a folder, but if you will check 9.7.2 PUT for Collections, you will see:
9.7.2 PUT for Collections
This specification does not define the behavior of the PUT method for existing collections. A PUT > request to an existing collection MAY be treated as an error (405 Method Not Allowed).
The MKCOL method is defined to create collections.
So there's no way to update existing folders, it's create and upload contents, indeed.
You can also check this article if you are interested in WebDAV protocol: http://amarchuk.blogspot.nl/2011/10/heres-c-webdav-client-that-works-with.html
A client has custom firewall rules around their website to prevent any number of attacks. One of the custom rules blocks all requests (either GET or POST) including a double hyphen, in order to prevent SQL injection. While updating their website last night, we had an issue where on every page, one of the calls to the ScriptResource.axd included a double hyphen(--) resulting in access to the script being denied.
We had seen this issue previously and thought we had worked around it by using the ScriptReferenceProfiler in order to generate the list of scripts we'd need to combine in order to remove so many script references. That was working until the update last night when the issue reoccurred. (Interestingly, I reran the ScriptReferenceProfiler and all of the scripts it identified were already included in the CompositeScript listing so I don't know where this file came from.)
I finally created a new IIS virtual directory where the issue with the double dashes didn't occur, despite pointing to the same directory and codebase as the previous virtual directory. (I set the initial virtual directory to act as a redirect to the new one so the users wouldn't have to worry about updating links or bookmarks.) I can see from this post that the first parameter is generated via encrypting the assembly name and resourcename which explains the difference in the values between the two virtual directories.
But obviously, I'd like to avoid this situation in the future. Does anyone have any thoughts as to how to prevent double dashes from appearing in the ScriptResource requests?
For reference, this occurred in a VB.Net website running in .NET 4.0 on IIS 6/Windows Server 2003. Additionally, the script file being rejected was for an Infragistics control of some sort. (I turned off the firewall rule briefly in order to get the file and then re-enabled it. I wasn't able to tell from the script what role it played for Infragistics, though.)
Thanks.
The first parameter (d) is the assembly and the resource. For the assembly, this includes the name and version as well as the public key token if the assembly is strong named. If any of these change then the string for the resource will also change.
The second parameter (t) is just for the timestamp and this allows the resource to change if an assembly containing an embedded resource is updated without the assembly name or version changing even if caching is enabled on a site.
The encryption of the first parameter is based on the MachineKey so you could change the MachineKey to change the string that results from the encryption. This may help you to have a simple workaround for the issue when it does come up even if you don't control the names and versions of all of the assemblies that you use.
Related reading that may be of interest to you:
machineKey Element (ASP.NET Settings Schema)
How To: Configure MachineKey in ASP.NET 2.0
Debugging ASP.NET 2.0 Web Resources: Decrypting the URL and Getting the Resource Name
I'm receiving "culture name 'uploads' is not supported" when my ASP.NET application start. Where do I have to view/debug to toggle the error?
A full-text search for "uploads" returns 0 entries in my project.
I've deleted this folder and it solved the problem:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\8dfb04ef\44bf70fb\uploads
Do not worry, it is not a real error.
When the runtime tries to find which resource assemblies exists, it tries to enumerate folders where compiled DLL files reside. It assumes the name of the folder is the culture name, so it tries to create a culture for it. Unfortunately uploads is a folder which is created automatically by ASP.NET, and it is obviously not a culture :).
The runtime ignores some predefined folders like "hash", but not "uploads". So we have to live with it.
I am getting the exact same error. ["culture name 'uploads' is not supported"]. I do not know what is causing it but I've been able to get around it by clicking [Debug|Exceptions (Ctrl-alt-E) and un-checking "Common Language Runtime Exceptions". I do not have an 'uploads' folder or file in my project and there is nothing in my project that has anything to do with multilingual support and the error fires right off the bat when I run my project ... looking at the call stack just walks me through a whole lot of mscorlib calls. I have no clue why it's even getting called.
JumpingLethalRampage, instead of unchecking all "Commong Language Runtime Exceptions," you could uncheck just "Common Language Runtime Exceptions > System > System.ArgumentException." You don't need to uncheck all CLR items.
It sounds like maybe you have some code somewhere that is trying to set the culture based on a URL pattern (this may be tracked down if it is possible to get a stack trace). For example, sometimes I'll set up multi-lingual sites with URLs like this:
http://www.example.com/en-US/
http://www.example.com/es-MX/
I'll then have code in my base page that looks at the URL and attempts to set the culture based on the URL path. But if you tried to hit a URL like:
http://www.example.com/uploads
It would fail with an error like what you are seeing if you just blindly take the first path element and try to use it as the culture without checking it first.
If the application is it built upon DotNetNuke (and not a simple ASP.NET application), this kind of error generally occurs in DotNetNuke due to the issue described in Culture name '__page' is not supported.
If you are not using DotNetNuke, check your Application_Start code (in the Global.asax file). It might be setting the CultureInfo. Or check your web.config file for any invalid culture values.
Assuming that your search through the project wasn't restrictive (widest possible search in all files), then my guess would be that your browser has a User language set to a custom string - "uploads".
In IE, you can check via Tools -> Options -> Languages -> Add -> User defined language.