We have a problem whereby the content editor is crashing the browser (any browser - Chrome, Firefox & IE) and then seems to lock out the session.
This issue seems to happen in waves - for most of the day it works fine, then for a period of time it consistently happens. An example trigger point is selecting an item in the content tree, then clicking the edit button. The page then freezes. Sometimes it says 'Not Responding' in the title bar, but sometimes you can still click into the address bar, yet the page itself is completely non responsive, almost like there is an overlay over the page, preventing anything being clicked. If the address bar is still available to click, going back to root URL just causes the site to hang and just continuously loads.
What's interesting is that when this occurs, users can load up a different browser and login fine (with the same credentials). So the issue seems to be connected to the browser session. But if the user tries to perform same action (clicking the 'edit' button for an item) in the new browser then it crashes too.
I have checked the JavaScript console in the browsers development tools and there doesn't appear to be any JavaScript errors & there is nothing in the logs to suggest a problem so we are a bit confused.
We have around 6+ content editors working concurrently.
After sending a dotTrace sample to Sitecore support, they have confirmed there was a bug in version 8.1 that was causing this. The reference number for the bug is 92994.
As a work around, they suggested the following:
As a workaround for the issue, please set value of the
Indexing.UpdateInterval setting to 00:00:00. It will disable automatic
updates of Quick Search (aka system) search index. This search index
is not used for searchin by Sitecore as Search.UseLegacySearchEngine
setting is set to false. Thus, indexing can be safely disabled
Since applying this workaround, our users haven't reported the issue.
Check to make sure you don't have a dependency hard-coded into your "Main Content" field that has been moved somewhere else in the content tree or deleted outright.
I've encountered this exact experience (freezing and then session lockout) when I moved a content item I had been linking to within an iframe. I had been using a hard-coded relative link and not a SiteCore link (otherwise, there would not have been an issue, since SiteCore auto updates internal links when content is moved).
The only solution I found with my particular issue was moving the updated content item back where it was, and then editing the "Main Content" field in the content item that referenced it (or restoring it to its original location, if it was deleted).
I realize your issue is not consistent, but it's worth checking out if you haven't already. If the changes that caused the freezing aren't yet posted to your staging or production environments, that could be why your users aren't seeing this happen constantly.
This happens on literally every Sitecore instance I've seen.
Sitecore uses synchronous requests in the admin interface - if you're looking in the browser console while in the admin interface you may notice that there's a stack of warnings about synchronous requests being deprecated because they may have a negative effect on user experience.
This negative effect is what you're experiencing, where the entire browser tab (or entire browser depending on which browser you're using) is locked and won't accept any input until the server responds.
Most of the time if you wait long enough (several minutes) the tab will become responsive again, but sometimes the server seems to just never respond and you just have to refresh the tab and find your place again.
To confirm that's what's happening when the browser is locked up, instead of looking for errors in the JavaScript console look in the Network tab of the developer tools for what request is taking a long time for the server to respond.
Related
A couple of days ago, I ran a collection of two requests in Postman.
I was using an environment variable created in the first request which was then
used in the second request.
I ran the two requests manually in the primary application interface of
Postman, one by one. The responses were as expected and there were no errors.
But when I tried running the whole collection in one go from the Postman
Collection Runner interface, the second request gave me an error.
I checked and double-checked that I was running the right collection. I closed
and reopened the Collection Runner window.
Also, in the Collection Runner window I tried switching to some other
collection, and then switch back to the collection of interest.
As I remember it, I even exported, deleted, and then imported the collection
again. None of these actions would make the error go away.
One thing I noticed was that - when running in the Postman Collection Runner -
the first request would create an environment variable with a stale name,
that is with a name I had used previously for the same environment variable.
However, when running the first request manually (not in the Collection Runner
window), the environment variable was created under its new correct name.
I cannot reproduce this behavior, and therefore I don't expect to see a genuine
solution to the issue. But a workaround would be much appreciated.
In vain I had tried just about anything I could think of.
Then I found a post at the Postman community on
How to remove some or all requests from the history.
See the second post of the link ( = first answer ). It says:
"There is also a Clear All selection at the top of the History section if
you want to remove everything."
In the Postman primary interface, just click
History > Ellipsis (...) > Clear all.
Voilà! - No error when running the collection in the Collection Runner window.
For navigation help, see the images below.
Is there a way in Oracle APEX to find out whether a particular dynamic action was ever used and whether a particular process ever ran?
Update: to make the question less broad, let's say there is a dynamic action called "DA 1" and I need to see if it has ever been used. Also there is a process named, let's say, "Status Change", how can I see if it has ever been run or is it dead in the water
These are two very different things.
Processes are PL/SQL processes that run server-side. Enable debugging mode, which can be done through the URL or the menu at the bottom of the page when you're logged in as a developer, then either reload or submit your page. Then click View Debug, find the entry for the page load/submit you just performed and your process will be listed in the output.
Dynamic Actions are small Javascript routines that run in the browser. Again, if you load the page with debugging active, then open the developer tools for your browser (usually F12), if your DA runs, there will be an entry in the console.
I am using Sitecore 8.1 and whenever I build the solution. Sitecore starts rebuilding all the indexes when I load the website in browser. I am using IIS (localhost) on the development machine. Even if I change a some thing in web.config and reload the website (in browser), sitecore starts rebuilding indexes again.
Is it normal behavior with Sitcore 8.1? I have recently started working with it. I never had this kind of problem with Sitecore 7.2.
When you update web.config, Sitecore initiated a shutdown and restart again, once Sitecore gets restarted, it will start updating the indexes (I can see this in the crawling log).
IntervalAsynchronous strategy will be triggered and responsible for this behaviour.
The strategy forces a full index rebuild when the number of entries in
the history table exceeds the number you specify in the
Indexing.FullRebuildItemCountThreshold setting. This normally means
that a substantial publishing or deployment has taken place, and this
should always trigger a full index rebuild.
Refer to this link for more information: https://doc.sitecore.net/sitecore_experience_platform/setting_up__maintaining/search_and_indexing/indexing/index_update_strategies
I've been happily developing away on a Sitecore project for the last couple of months. This evening I did what I have done 100 times, smart published the entire site so that I could view it from the web DB as an end user.
When I navigated to the site I discovered that all of my content is gone. All rendering elements are there, but anything in the /sitecore/content tree is missing on the page. Gone. Empty. Nada.
Everything looks fine when I'm logged in and viewing in Page Editor.
I've done several smart publishes and still the same. I was going to try a republish of everything, but after reading the warning dialog I thought I'd wait until I understand what happened.
This is a pretty disconcerting thing. Any one have any ideas?
Check your root or home item , make sure it is in publishable state and check if it published. If the root item is gone your will not see anything on the site.
There are multiple things you will want to check on your root node where content is missing:
Workflow state: If there is only one version, but the workflow state was changed to a non-final version manually, it will not be published.
Publishing Restrictions Publishable state: If the 'Publishable' checkbox has been disabled for any item or version, that item/version will not publish.
Publishing Restrictions by Date: If a date-based publishing restriction has been applied to the item or versions, the item may have been removed because it is no longer in a publishable date range.
If this is on Sitecore 7.2, i think there is a bug where content items just disappear:
http://maxslabyak.com/sitecore/3-new-sitecore-v7-2-bugs-need-know-go-live/
To Fix it, set this setting Publishing.PublishEmptyItems to true
Hope this helps
In our sitecore project (6.6.0 rev. 130404), we are facing an issue when trying to rebuild large indexes using sitecore control panel. There is an index which contains more than 650,000 items. Half-way through the index rebuilding operation, the process stops with the error "job ended unexpectedly" being displayed on the index-rebuild dialog box. When analyzing sitecore logs, we can't find any recorded exceptions related to this. Because we didn't know when the index rebuild really stopped, I searched all sitecore logs for the word "Exception" but couldn't find anything related to this.
We face the same issue with QuickSearch index (even larger index than our own) as well.
In logs, we see "Index rebuild job started" message but nothing related to that being ended or interrupted.
What can be the possible causes of this? and how can I find evidence using sitecore logs?
(ps. I have previously sought help for good indexing practices on this post, but haven't implemented the suggestions): Sitecore index rebuilding practices)
If you have permission to do so: Try to look into the EventLogs on the server you are hosting your solution on. Also, do you see logs like "Hosting Environment Initiated a Shutdown" or anything like this? There might be alot of reasons for Sitecore to be shutdown and showing this error. From my own experiences this can be:
Application pool with memory restriction exceeding limits and causing a shutdown;
Application pool rapid fail protection that shuts down the pool;
Changes in the Website/Data folder; (data folder can best be placed outside the website folder);
Application pool recycle times -> can be scheduled and cause application pool to recycle;
Those were just a few of the things I found to be the cause of recycles sometimes. You might best now check your eventlogs and from there try to shutdown the above stated causes.
EDIT: Ensure the data and indexes folders are outside of the web root and update the web.config to point to the data folder.
Hope this helps you a bit.