menu_get_item() that is used in the module doesn't handle url language prefix. I fixed that but after that when wysiwyg+tinymce restores text it looks smaller though HTML button shows the HTML is the same. And when Save button is pressed, it turns out that form action is changed by prepending the language prefix, e.g. from bg/node/1/edit it's changed to bg/bg/node/1/edit and naturally Page not found error is shown.
Anyway, I'm attaching my fix for menu_get_item().
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | autosave_language_check-1585408-7.patch | 708 bytes | deciphered |
| #4 | autosave-languageCheck-1585408.patch | 1.41 KB | hey_germano |
| #2 | autosave_get_menu_item.patch | 2.28 KB | quicksketch |
| autosave-lang-prefix.patch | 1.98 KB | ogi |
Comments
Comment #1
quicksketchAre you reporting two separate problems here? I'm not clear on whether two problems should be fixed. If so, please open a second issue with that problem. Regarding the language prefix problems, could you describe how to reproduce the problem? I think you may be describing #1617032: After restoring a form, subsequent autosaves written to db with wrong path.
Comment #2
quicksketchThanks for reporting this problem with the language path prefix. I could confirm the problem (autosave basically didn't work when using a language prefix), and the fix worked great. I cleaned up the formatting a little more and committed the attached patch. I made a separate issue for what I think you described over in #1678806: Fonts/CSS don't apply properly after loading an autosave. Thanks!
Comment #4
hey_germanoOn a site with only one language, I was getting this error when trying to restore an autosave revision:
PHP Fatal error: Call to undefined function language_negotiation_get_any() in /path/to/drupal/sites/all/modules/contrib/autosave/autosave.module on line 379I read through some API stuff, and it looks like language.inc is only included on sites with multiple languages. So on sites with just one, I believe that error will always come up. It was preventing the autosave functionality from happening at all.
This patch just has a wrapper around that language function that checks if you've got multiple languages running or not. Fixed the issue for me, at least (running latest dev version of autosave).
Comment #5
pumpkinkid commentedI had the problem described in #4 until I applied the patch...
I was seeing this problem on a brand new node creation form and when it would come up for restore, it would error out.
As soon as I applied the patch in #4, I was able to restore the autosave, but it does not continue to autosave past that point.
Also, using admin overlay, the restore makes the overlay much bigger than it needs to be.
Comment #6
agentrickardMakes sense, but no need to nest the initial IF statements. This is perfectly readable:
Comment #7
decipheredRe-rolled patch with the suggested change and a fix for the patch base directory.
Comment #8
agentrickardComment #9
remaye commentedStill does'nt work for me with patch in #7 (7.x-2.x-dev)
Save button link to the page adding the default language prefix to the correct url (and of course doesn't save restored version) :
If I'm editing "/en/node/nodeid" it link to "/en/en/node/nodeid".
If I'm editing "/fr/node/nodeid" it link to "/en/fr/node/nodeid".
Notice when I'm on a french node form, the Save button is labeled "Enregistrer" and after I click the restore link, Save button label become "Save".
Comment #10
mikemadison commentedI can confirm that the patch in #7 does fix the "importing of autosaved" data issue, but I can also confirm that once doing that autosave no longer seems to function.
Autosave continues to function just fine on pages that have not been restored.
Comment #11
gugalamaciek commentedI've installed new 2.1 verison of the module and I have still problem similar to described in comment #9.
When I click to restore form and then save form using button, it redirects me to page e.g. /en/en/node/nodeid instead of /en/node/nodeid.
I'm using drupal 7.18 on IIS7.5, MSSQL.
Comment #12
gugalamaciek commentedI've changed line 201 of autosave.module from:
$form['#action'] = url($record->path);to:
$form['#action'] = '/' . $record->path;I'm not sure if it's right way to do it, but it works for me.
Comment #13
dave reidI committed #7 since I was also getting the PHP fatal error on a fresh site install. Let's ensure any other follow-ups are filed as separate bug reports now since there seems to possibly be issues with saving on a multilingual site.
http://drupalcode.org/project/autosave.git/commit/48bce20
Comment #15
plachRelated issue #2229951: Stale autosaved data not cleared in multilingual environments.
Comment #16
pixelpreview@gmail.com commentedthe solution that works for me is :
line 228 in dev version
$form['#action'] = url($record->path, array('language' => array('language')));
If I add the array language in the url function, I don't have redirect like :
/en/nl/node/nodeid
Comment #17
g-brodieiI have the same condition of redirecting from /zh/add/webform/ to /zh/zh/add/webform when I try to save the node. Working on a multilanguage site using prefix.
The solution from @pixelreview worked for me.
added manually on line 315 in dev version, autosave.module file.
from
$form['#action'] = url($record->patch);to
$form['#action'] = url($record->path, array('language' => array('language')));Drupal 7.56
autosave 7.x-2.x-dev