Support for autosave module.
| Comment | File | Size | Author |
|---|---|---|---|
| #50 | autosave.js_.patch | 606 bytes | geek.de.nz |
| ckeditor-autosave.patch | 2.33 KB | mephir |
Support for autosave module.
| Comment | File | Size | Author |
|---|---|---|---|
| #50 | autosave.js_.patch | 606 bytes | geek.de.nz |
| ckeditor-autosave.patch | 2.33 KB | mephir |
Comments
Comment #1
mephir commentedIssue on Autosave module page was added(http://drupal.org/node/653254). Waiting for autosave compatybility and patch implementation.
Comment #2
Equinger commentedsubscribe
Comment #3
bryancasler commentedsubscribe
Comment #4
nancydruWaiting for this too.
Comment #5
nancydruWhy is this patch here rather than the Autosave project queue?
Comment #6
liquidcms commentedNancy, i am not sure you understand the wysiwyg api concept. The intent of this API is to create a standard interface between Drupal modules and the slew of JS based editors out there.
To that end; Autosave works (now in D6) using standard (once they commit the patch) wysiwyg API calls. If i didn't do this i (and other module designers) would need to write custom code for each JS editor out there. This way we just write for one API.
The issue is that the wyswyg api project may not "fully" support all the editors that it suggests it does. Once they add "Full" support between their API and the CK editor - then Autosave (and likely numerous other modules) will automatically work with it.
so that's why this is not an issue with Autosave - we don't explicitly support ANY editor - we support whatever wysiwyg api supports.
Comment #7
liquidcms commentedahh.. yes, i see that the original poster submitted a patch to make Autosave explicitly work for CK... yup, that will never get committed. sorry.
what he needed to submit was a patch (which i think is only a few lines of code) to map the ck call to the w-api call.
Comment #8
liquidcms commentedComment #9
nancydruI was not the one who chose or installed CKEditor. I do not know why they decided not to use WYSIWYG. However, there were so many issues with getting it set up right, that I seriously doubt that they will okay adding WYSIWYG into the mix.
Comment #10
jcisio commentedfckeditor.module and ckeditor.module count 90,000 users. I don't know if all of them have a reason behind it, but I'm sure some have. It's a pity that Autosave does not support it.
How to map w-api to ck if I don't install wysiwyg at all? I'll test this patch, thanks mephir.
Comment #11
nancydruIf it works for you, you may have to re-open this issue, but it sounds like the maintainer has made up his mind to not support it.
Comment #12
jcisio commentedI understand that the Autosave maintainer doesn't want to commit this. But I'd like to confirm that this patch works well.
Comment #13
dczepierga commentedI think we should intrested in this patch - so i decieded to review it, probably make some small fixes and it will be as feature for release 1.3.
And really thx for good work.
Comment #14
nancydruAwesome. thanks
Comment #15
rwohlebsubscribe
Comment #16
nancydruAs much as I'd love to have this, the patch is to AutoSave, not CKEditor. The AutoSave maintainer has marked #653254: Autosave with CKEditor module as "won't fix" just as liquidcms did.
Comment #17
jcisio commentedWell, CKEditor may emulate a minimal functionality set of WYSIWYG module to let AutoSave support it.
However, the issue that mephir posted was not "won't fix" by AutoSave maintainer, but ironically by WYSIWYG maintainer in #653254: Autosave with CKEditor module.
Comment #18
jcisio commentedSince 1.2 was out, marking it as active.
It seems that emulation is quite simple. We need to emulate:
I don't have time to test it right now, I'm not sure if the first line is passed by reference. I'm using a patched Autosave.
Comment #19
nancydruThis goes where? Are we still requiring that WYSIWYG be installed? Is the patch you're talking about the one from the OP?
Comment #20
jcisio commentedNope, it's not the patch from the OP. It emulates WYSIWYG module. Add those lines at the end of ckeditor.util.js should work with the current version of Autosave. The original patch (for Autosave) is no longer required.
However I don't bother to test it as I don't use it now (sorry!). I hope dczepierga take care of it soon.
Comment #21
wwalc commentedComment #22
Hiroaki commented#18 worked (but not with non-clean URL setup)
Comment #23
Hiroaki commentedcan someone teach me which version of both Modules I must have for this patch to work?
none of the allegedly available "autosave" works, whether Draft or Autosave.... ;______;
by the way, i found this post on google, it might help:
http://cksource.com/forums/viewtopic.php?p=39453&sid=b59b3b8714a98c5c058...
Autosaving is such an important part of text related tools, and yet no side is trying to commit this function somehow...?
Comment #24
liquidcms commentedThe only valid version of Autosave is the latest released version 6.x-2.7.
Beyond that i am not sure what the current status of the various patches is. From the sounds of this post there are 2 ways to go:
1. use the patch for autosave listed here
2. (preferred) use the code in #18 to "patch" CK.
I am not sure how well either of these work. #18 is a bit unclear as it states he used patched version of AS but then later says this isn't required. From the sounds of it; the latter is true as the approach sounds like an attempt to make CK emulate WYSIWYG module.
and..
3. use WYSIWYG (which is what AS is designed for) and bug the W guys to get caught up.
Comment #25
Hiroaki commentedThank you for replying, i will report for each one of the result.
1.
I used clean Drupal website
CKeditor 6.x-1.2
Autosave 6.x-2.7
above modules were activated, autosave set to 5 seconds.
Ok, i missed the part in read me where i had to turn on autosave for "each" content/type i was testing.
It keeps showing that form has been autosaved, yes, but the database is not filled right with non-clearn URL.
this issue probably: http://drupal.org/node/618342
(
somehow my drupal says i cannot use clean urlI set up apache correctly and now clean URL is working)I tried this setup again (autosave patched for CKeditor, no #18), same result as 2, the module autosaves the previously saved file.
2.
Reinstalled Autosave 6.x-2.7 (none patched)
module/ckeditor/includes/ckeditor.utils.js got the lines from #18 at its very bottom
autosave's function seems working, but above problem (non-clean URL not working issue) persists here in a strange way.
I've applied the patch from the issue and it saves the form on to a table called autosave_forms, but it saves the previously saved data. and not the data in the current CK form, this maybe that #18's method of getting the form's current data is wrong and its getting the data from the previous saves and passing that to autosave module?
3. probably the same with 1
I also tried Draft module for its autosaving functionality, the function didn't work either. (i enabled Draft for each content type to check it)
Comment #26
liquidcms commentedthanks for posting the test results.. not sure who is listening though.. i will state my case yet again.
i am the defacto-maintainer of the Autosave module (although this work was funded by the NY Times originally and they are no longer funding this work - but i will continue to support it when i have the time to do so).
When i was redoing this module for D6 i asked the WYSIWYG api module guys what the future of w-api was and they stated this was the correct approach. It did make sense to me; unfortunately they seem to have possibly gone by the way side as far as support for D6 and i am not sure of the plans for w-api in D7 although i have heard in general their is intended to be better support for wysiwyg editors in D7 (which is good; since one of Drupal's worst selling points).
As it is; the decision for AS was to work with w-api. This does seem sound as it means that i don't need to worry about 15 or so JS editors out there and only need to write code to support w-api. AS (ver 2.7) works fine without a JS editor. With W-api it also works fine assuming 2 things:
1. that the patch mentioned on AS project page is applied to w-api (sad that w-api maintainers have not commited this simple patch after over a yr).
2. that the JS editor has "full" support within w-api (CK does).
The patches listed here appear to be 2 different methods of getting CK to emulate w-api. Cool, although not sure why you don't just use w-api as that is tested and known to work. But if you want to go the route of using the patches here - good luck.
Comment #27
Hiroaki commentedwell, yeah i was thinking of trying out the WYSIWYG module with Autosave with wysiwig patch, the only problem is, their support for CKeditor isn't perfect, the button wrapper is messed up so all your buttons are spread across entire window and such.
If pointed out they just say "it will be better in api 3.0" or something that NEVER comes up.
I've tested with WYSIWYG + Autosave, and it works. so this (correct form not saved) is likely the problem of this patch or the WISYWYG emulation code. It is getting close tho. I'd like to use CKeditor Module rather than WYSIWYG, so I ask this thread to keep going and hope it solves the problem.
Comment #28
jcisio commentedThe question is simple: I'm using CKEditor.module so I can't use the WYSIWYG API. AS is not the only difference between the two modules.
My question is simple: Why you can't simply commit a 10-line patch to support a module with an increasing 35k+ user base?
Second question: What will make you commit this patch? Would you mind if CKEditor.module includes a sub module with exact functionality as autosave (well, it's rather sad in that case).
Comment #29
liquidcms commentedi was pretty firm on the idea of not supporting 10+ JS editors mostly because my client didn't use any of them (we were using Tiny) and the w-api guys ensured me this was the future of js editors. seemed to make sense as it is clearly the right way to go.. clearly!!
however w-api seems to have dropped the ball in not being able to keep w-api feature rich enough or supported enough to do what it has been claiming. i think it has a few key issues (although not been keeping track; perhaps some of these have been solved):
- too complex to set up
- no mechanism to support textareas which do not have input formats assigned to them (i.e. most std admin text areas)
- not keeping api up to date with simple patches like the one jide provided to allow AS to work
so.. that all being said.. i don't want to support the slew of js editors out there.. but i will reconsider committing this patch to add on support for CK (but won't test and if anyone reports it breaks anything in AS.. well.. out it goes.. )
won't get to it until tomorrow though..
Comment #30
liquidcms commentedmoving this to Autosave project and marking as Needs Review as i have committed patch listed in initial post of this issue
Comment #31
liquidcms commentedpatch is included in 6.x-2.8
Comment #32
liquidcms commentedComment #33
jcisio commentedIf patch committed and new version has been released, then it is fixed ;-)
Comment #34
Hiroaki commentedThank you, liquidcms!
I checked 2.8 in new drupal installation and it worked! Maybe i was messing some code up when testing the patch.
Comment #35
antongp commentedHi. I'm using 2.8 and I have one problem: when click "ignore" I expect that module will ignore autosave and let me to edit saved version of the node, but the module clears all content I have in the field. The same happens if click "View" and then "reset"/"ignore".
So, I've looked in autosave.js file and seen this code (lines 43, 60):
CKEDITOR.instances[instance].setData('');I really don't understand why it's used instead of:
CKEDITOR.instances[instance].setData($('#' + instance).val());So, maybe I'm wrong, and such functionality is conceived as it is. Waiting for your comments:) Thanks:)
Comment #36
bryancasler commentedI agree with #35 +1 for changing the function of ignore
Comment #37
jcisio commentedI had the same issue but I think that it is not related to CKEditor ;-)
Comment #38
antongp commentedYes, of course:) This is related to Autosave project, particularly to attached patch. And I don't agree with status of the issue (which is "fixed"). "Ignore" link don't clear content if CKEditor is't used, so it should work in such way if CKEditor is used.
I've written the solution above (#35). So, another solution is:
switch to plain text editor -> ignore autosave -> switch to rich text editor :)
Comment #39
liquidcms commentedat a bit of a loss here guys as i don't have (or want) to install CK to test this. Took it from #33 and #34 that this was working (although i didn't mark as fixed).
i agree with go13... "Ignore" should not wipe the content and therefore the patch provided at the top here, which i thought was tested and therefore committed, does not work.
can anyone confirm that the "patch" in #35 fixes this issue?
Comment #40
bryancasler commentedPatch in #35 works for me, haven't noticed any side effects.
Comment #41
liquidcms commentedi have made the change from #35 to -dev but sadly i don't know how to get the -dev version to show on project page.. guess i will need to make a new release.. would prefer to let -dev get some testing by community first.. but can't see anyway to add it to project; so.. :( this will be 2.9 rev
Comment #42
jcisio commented#41 you can make HEAD your 2.x-dev, or just create 2.0BETA1 :-) Anyway CVS sucks.
Comment #43
nancydru@liquidcms: Go to "Administer releases" on the project page and you will see "Show snapshot release" for each branch. It may take the next build cycle (Noon and Midnight GMT) to show up.
Comment #44
liquidcms commentedyou mean like this: http://screencast.com/t/6WjH2gqrTb ?
already set that way.. doesn't work.
Comment #45
jcisio commentedAs I said CVS sucks ;-) File an issue in Webmaster queue to get it fixed. My experience is that never develop in HEAD, always create a branch and dev in it.
Comment #46
nancydruIt always works for me. As I said, you may have to wait for the next build cycle.
Comment #47
liquidcms commentedbeen waiting since d.org switched themes... pretty sure its busted!!
Comment #48
nancydruLike jcisio said, then file an issue with Webmasters. Dww will probably fix it.
Comment #49
claar commentedsub
Comment #50
geek.de.nz commentedHi, For me the attached patch worked fine. Only found these patches after I wasted time and fixed it myself. The maintainer(s) were not really communicative with a previous fix I did for http://drupal.org/node/1402902, just:
"I don't really understand what your patch is doing, please comment your code...".
I commented and uploaded another patch, but got no reply to that. So, I thought, bugger it's not going into trunk. It seems like lots of people have issues with this module and the main maintainer(s) cannot be bothered adding other maintainers which is fine if they were at least applying patches and reviewing them.
So, against all recommendations I made my own "fork" on GitHub: https://github.com/geekdenz/drupal-autosave
There is another problem with the module that I'm about to fix: When restoring a node autosave stops working.
Feel free to fork it, because I will be working on this in the near future and looking at pull requests.
This is a fork off the 7.x-2.x branch. I will also be merging in the trunk version on a regular basis at least until I got it into a state where it is stable, because it's an important requirement on a project.
Comment #51
liquidcms commented@geek: not sure why you are posting this on this issue... CK support has been added to 6.x version quite some time ago
marking this as closed. if you have issues with 7.x; or issues in general with CK support; or ck support in D7; please raise a separate issue.