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
Related
We're integrating SAP Commerce 2005 and Spartacus 2.0.3 with CDS (Context-Driven Services). We followed the instructions from https://sap.github.io/spartacus-docs/cds-integration/ and we got it work right.
Nevertheless, we've noticed one issue.
When we clear the site data (either from Chrome DevTool or via browser Settings), the cookie named profile.consent.given is not being set anew while refreshing the page - even though the PROFILE consent has consentState "GIVEN" in local storage in spartacus-local-data > anonymous-consents > consents.
Initially I thought that it's just not visible in DevTools, but when I've added the url parameter ?profileTagDebug=true, in the console there is a log saying:
"[Profile Tag] No cookie found with name profile.consent.given".
When I set this cookie manually with value true, everything starts to work just fine, all other needed cookies and local storage data responsible for tracking users behavior is being set properly.
Do you see any place where we could have done something wrong, which may have caused this cookie to work improperly? Which module or component of Spartacus library would be of any clue in resolving this issue?
Edit: the reason of this strange behavior was in profile tag created by our team in CDS. It contained:
"consentListener": "type":"cookie","cookieName":"profile.consent.given","cookieValue":"true"},
which made the cookie profile.consent.given necessary while it shouldn't be. Using profile tag without this part made all work just fine.
With Spartacus, this cookie doesn’t make sense anymore. It is created by the Commerce backend and works best in combination with an accelerator frontend. Cds-spartacus in combination with ProfileTag relies on the anonymous consents or the user consents (depending on the user being logged in or not) loaded by Spartacus. More information about anonymous consents can be found here: https://sap.github.io/spartacus-docs/anonymous-consent/.
Just a quick FYI about the CDS-Spartacus integration: the profile tag script is pulled from the configured URL by Spartacus, and the script is doing all the event and data "scraping". The cookie is also being placed in the browser by the script.
Your question and this comment lead me to think that the script is not handling this case.
I'm not even sure if it should handle it, so it might be a better idea to contact CDS team directly about this one.
I see an error using CFCHART with Lucee. Same code works in CF. But in Lucee it try to refer to a file graph.cfm in a folder lucee.
mytestserver.com/lucee/graph.cfm?img=026f01d7b8c85b891a9c35c102623747&type=png
Do I need to create any mapping? Should this mapping be in Lucee admin or in IIS?
The short answer is: No, you don't need to add any additional mapping in IIS, nor in Lucee or Tomcat.
I've seen this question here for too long, so I'm placing an answer here to shed some light into Lucee's graph.cfm.
Some tags in CFML need to create additional image files to later embbed them as an inline HTML element into the reendered output altogether. Examples for such file creation are <cfimage type="captcha" ...> or like you have already noted in your issue, <cfchart>.
For such functionality Lucee needs to create these files temporarily somewhere and also make them publicly available. To achive this for cfimage/cfchart, Lucee creates the files in the web context folder of your webroot (which typically is located at path-to-your-webroot\WEB-INF\lucee\temp\graph ) and embbed them inline with a link to graph.cfm. The template graph.cfm just reads the temporary file from that folder, and delivers it in realtime to your application.
If you want to take a look into Lucees original graph.cfm, we can take a peek thanks to OpenSource:
source of Lucees graph.cfm at github
In order to make the files and the template graph.cfm temporarily publicly available, which by the way sits behind the WEB-INF folder ( which is also hidden/blocked by default in Tomcat for securtiy reasons), Lucee MUST have a virtual mapping. But you don't need to set it up, because these are already set up by default. You can see this in the image below taken from the "Mapping"-section of Lucee Administrator:
Because graph.cfm is a .cfm file, IIS will redirect the request directly through the implemented CFML connector ( probably Boncode Connector ) per AJP to Tomcat. Thus you don't need to set any mapping in IIS neither.
Because you have not submitted any additonal error information, such as http error codes or stack traces, I don't have any clue of what might be the cause of your error. It may also be some incompability issue which might be addressed if you submit it to the Lucee core team.
Another possibility is that many installation guides advise you to lock down the "/lucee/" path with IIS URL Rewrite Module, because this is also the path where the Lucee Administrator sits behind. If so, you can change the setting in IIS Rewrite Rule and adapt the rule in such a manner, that it would not block the graph.cfm.
It's also important to note that many of these cftags are implemented as Lucee extensions (.lex files). These are not necessarily pre-shipped or pre-installed in Lucee, but you may install it within Lucee Administrator or get them from Lucees Download site and upload it through your Lucee Administrator in the "Extension" section.
I've just encountered this too. Issue being though the the default mapping still don't navigate to "graph.cfm" so we've added an IIS virtual mapping instead.
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.
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.
Has anyone run into an idea of a "settings app" for a django project?
It's a set of application variables set by an administrator (not developer, so settings.py fails) using admin panel.
Are there any apps ready to use?
edit
I probably didn't state my question clear. I don't mean editing the things like connection settings, rather things like "file size limit".
There is a very nice app that does this, called django-dbsettings. The official repo hasn't been updated in years, but I have an up-to-date fork on my github page.
The question is how would you store the settings.
Cause... if you store the settings in the database it will be troublesome since most of the code will already be initialized (using the settings before that) before you have a database connection.
If it's the filesystem that means you're going to have to include a Python file that's being modified by your webserver which sounds like a huge security risk to me.
So... in my opinion, it could be done but I would vote against it since it's dangerous. If things should be configurable from the web, implement that in the app :)
It sounds a bit like you're asking "how does an administrator change the settings (like database connection parameters) without changing settings.py?"
If your admin isn't familiar enough with python to change the settings.py file directly, you might consider giving the admin a simpler file to edit, perhaps a config file that you loaded from settings.py. Then all your admin has to do is edit the config file and restart the server.
This has an added benefit that you can limit the config file to only those parameters which your admin would need to mess with (like database connection parameters).
(Another option would be to get a better admin ...)