Is there a way to listen undo / redo stack events in CKEditor 5 - ckeditor5

I would like to automatically save the content of the CKEditor 5 on the server as the user edits it.
I could listen to the change:data event, but it gets triggered on each keystroke. So I would need to implement some kind of debouncing strategy to avoid flooding the server.
Which brings me to the undo / redo stack. The Undo plugin seems to be doing a good job at batching changes (luckily you don't get one entry per keystroke!), so I was thinking to watch the stack and trigger a save each time an entry is added (or is done or undone).
How can I achieve that?

Oh boy, I just learned about the autosave feature that solves this problem. Nevermind the undo / redo stack then.

Related

Reload on Solr (Google Cloud)

I was having issues with submitting a document into Solr on Google Cloud and read somewhere that the issue should be resolved by committing.
I couldn't figure out how to commit on Solr(noob) and pressed a button called reload. The error went away, but I'm afraid I messed something else up. Can anyone explain what reload does compared to commit, or confirm if reload was fine?
No, reload isn't fine if you want a commit.
The reload command tells solr to update some core based on a new configuration (solrconfig, schema and another config files). Even if it work in your case, it's not meant for the purpose of commit.
The commit command tells solr that the data sent to it should be searchable ASAP. I guess it's what you're looking for.
For this you can configure automatic commits and/or soft commits in solrconfig.xml. There's also a URL you can call to achieve this, which is something like this: http://localhost:8983/solr/mycollection/update?commit=true
I recommend you to read this docs:
Commit
Reload

How do I disable "activities" for a custom module on SugarCRM 6.5+ 7+

The title is pretty clear but again: How do I disable "activities" for a custom module on SugarCRM 6.5+ 7+
I have a module containing millions of records and activities has been slowing it down to a breaking point. I managed to stop the activities through some hacking (deleting entries from the cache folder) but I would like to know how to do it the right way so on repair&rebuild + etc things will be normal/ok.
//edit1:
I'm happy to completely disable activities for a limited period of time while my script runs and then enable it again right after if that is possible.
Well, I figured out how to disable activities (activity stream, known in the past as sugar feed I think).
As my problem was running a script on 100k records etc disabling the whole activity stream temporarily in the beginning of the script and then turning it back on in the end was sufficient.
It's quite simple and it feels like an embarrassment I didn't look into the activity stream's source before since in order to disable it a simple:
Activity::disable();
does the job and to turn it back on:
Activity::enable();
There is also a "blacklist" array in the source etc but 1- It didn't solve the problem and 2- It's clearly not upgrade safe etc.

Lion previous versions working for restore, but UI bindings not updated after performing restore

I'm working on an app currently, and was scratching my head thinking that previous versions wasn't working; however it turns out that closing the document window and re-opening after a restore the restored values are now displayed.
The problem arises after performing the restore, the UI simply doesn't reflect that a restore has taken place.
Does anybody know of why this could be / how to fix the issue?
Thanks,
Clint
Have you implemented the required API for restoring the UI state of your windows? If you don't know what I'm talking about, you need to read this section of the documentation.
Turns out, it had nothing to do with the restoreFromCoder etc.
It was where the document object was being stamped over each time, this doesn't update the UI as UI updates a performed when a property is set, thus resulting in the binding being invalidated.
The way I got around this, was by every time it loads from a document, it simply "assimilates" the new document objects values into the existing ones (initialised to defaults in init); this results in the UI updating seamlessly when the user restores.

Undo an Update in AccuRev?

How do I undo an update in Accurev? I want to revert to a state where contents of the files are exactly how it was before an "update" operation?
There are numerous ways to change the contents in your workspace to reflect an earlier configuration. Based on the limited description where you reference "all the files under CM", I'll make the assumption that you want to roll back your entire workspace as opposed to a select few files.
Question: does everyone parented by the same stream as your workspace want to roll back, or just you? If it's everyone, you can change the time basis of that parent stream to reflect the specific point in time you want to revert to. Once that is done, run Update, and you're good. If it's just you and it's more than a small sampling of files, I'd suggest creating a personal time-based stream, setting the time to when you want, and re-parenting your workspace to it:
Current_parent -- New_personal_time_stream -- your_workspace
There are other options as well if you just want to deal with a few select files, but it seems like this is what you're after...
Cheers,
~James

How to override edit locks

I'm writing a WLST script to deploy some WAR's and an EAR. However, intermittently, the script will time out because it can't seem to get an edit lock (this script is part of a chain of many other scripts). I was wondering, is there a way to override or stop any current locks on the server? This is only a temporary solution, but in the interest of time, it will do for now.
Thanks.
You could try setting a wait period and timeout:
startEdit([waitTimeInMillis], [timeoutInMillis], [exclusive]).
Are other scripts erroring out, leaving the session locked? You could try adding exception handling around those. Also, if you have 'Automatically acquire lock" enabled in the Admin Console and you use the admin console sometimes it can cause problems if you are running scripts at the same time, even though you are not making "lock-requiring" changes.
Also, are you using the same user for the chained scripts?
Within WLST, you can pass a number as a parameter to gain an exclusive lock. This allows the script to grab a different lock than the regular one that's used whenever an administrator locks from the console. It also prevents two instances of the same script from stepping on each other.
However, this creates complex change merge scenarios that are best avoided (by processes).
Oracle's documentation on configuration locks can be found here.
Alternatively, if you want the script to temporarily relieve any existing locks regardless of the pending changes, you may as well disable change management from the console, minimizing the inconvenience caused.
WLST also contains the cancelEdit command that you could run before you startEdit. Hope one of these options pan out!
To take the configuration change lock from another administrator:
If another administrator already has the configuration lock, the following message appears: Another user already owns the lock. You will need to either wait for the lock to be released, or take the lock.
Locate the Change Center in the upper left corner of the
Administration Console.
Click Take Lock & Edit.
Make your configuration changes.
In the Change Center, click Activate Changes. Not all changes take
effect immediately. Some require a restart (see Use the Change
Center).
As long as you're running WLST as an administrative user, you should be able to jump into an existing edit session with the edit() command - I've done a quick test with two admin users, one in the Admin Console, and one using WLST, and it appears to work fine - I can see the changes in the Admin Console session inside the WLST interpreter.
You could put a very simple exception handler around your calls to startEdit that will log the exception's stack trace, but do nothing else. And then rely on the edit call to pop you into the change session.
Relying on that is going to be tricky though if another script has started an edit session and is expecting to be able to commit that change session itself - you'll be getting exceptions and unreliable behaviour across multiple invocations.