This site has been archived and you can no longer log in or post new messages. For up-to-date community resources please visit

eZ Community » Blogs » Arne Bakkebo » eZ Autosave and the content edit...


Arne Bakkebo

eZ Autosave and the content edit interface

Monday 03 March 2014 2:06:31 pm

  • Currently 5 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

I have had a couple of problems related to eZ Autosave the last year, which have been quite a challenge to figure out. So in case someone else might have the same problem, I'll make a note of it here.

The problems

Both problems are related to admin interface editing, and the symptoms where as follows:

a) When tabbing between two different drop down box (Selection) attributes, the keyboard focus suddenly disappears and can't be found again until you reload the page. This happened on Safari and Chrome, but not on Firefox, and the browsers seemed rather conflicted about how to handle it.

b) When editing a content object, and then publishing it, the eZ Formtoken throws an exception because the token is wrong, and the content object isn't published. This happened to only a couple of editors, and in maybe two out of three times when publishing. It was quite impossible to reproduce it for anyone else, including me and eZ Systems support.

At first, these two problems does not seem related at all, and it took quite some time before I found the connection. Both was clearly connected to eZ Autosave though, since when I removed it, none of the problems showed up.


The first problem, a), I could reproduce myself, so I quickly found that the eZ Autosave extension, when saving the working copy, also generates a preview html based on the frontend design. When I forced it to skip this process the problem disappeared.

I then found that when removing the whole pagelayout code, the problem also disappeared, and from there it was a question of reducing the right blocks of code to figure out that the reason for the problem was the frontend search box. For this site we have a search box on all frontend pages, and the trick about this search box is that it is given auto focus on every page. So when eZ Autosave generates the preview code, the auto focus is also set to this search box, and the browser loses focus from the edit fields that the user is currently working on.

Now, this was the simple issue. Then b) came along, and just made me totally puzzled. Since we where not able to reproduce it, I had to bother the customer every time I had a new idea for a possible solution or needed to log something to understand what was going on. We could see in the log files that something was obviously going wrong with the users session here, so it wasn't just the editors imagination. I talked to the editor on Skype (they where 1200km away, so I could not easily visit them), and concluded that there wasn't anything apparent they did wrong when editing. I had tried logging in to their account, but still could not reproduce it. So my theory was that there was something on their computer that forced the user session to change. I could not grasp what though.

At some point the customer decided that we needed to figure out what was going on here. So I sat down with the editor in question and just logged and tested everything I could think of, and reading every line in the kernel code that related to index.php and the session change. After a few hours it occured to me that the login functionality in frontend might have something to do with it, and tested that also this problem went away when I emptied the frontend pagelayout.

The frontend also have a popup box with a login form, when the user clicks on a tab it pops up via javascript and the user can log in. Wisened by the a) problem, I tried removing all related javascripts. This did not solve it. However, I found that if I removed the whole login box, or any one of the login/password fields in it, the problem disappeared.

Then the revelation suddenly came to me. The editor in question where using Lastpass, a program that could automatically log in the user to any login form that showed up in the browser. Naturally, when eZ Autosave tried generating the before mentioned preview, the login form was also generated. Lastpass detected this, and automatically logged in the user while he was editing his object. This relogin made eZ Publish regenerate the editors session. This session regeneration made eZ Formtoken regenerate it's token, and when the user then tried to publish the current object the old token still residing in the admin edit form mismatched the new session token, making eZ Formtoken throw an exception and crash the program. And when the editor tried disabling Lastpass, lo and behold, it worked. :)


I solved these two problems as follows:

a) In dialog with the customer, we decided to set autofocus on the search field only on the frontpage of the site. This limits the problem to only editing of the frontpage, which doesn't have drop down boxes.

b) I added code in the login popup box to check if the current url contains '/content/versionview/', which indicates the eZ Autosave preview function. If this is true, I just do not display the login fields.


Be aware that the eZ Autosave preview, which is generated whenever an edit field is losing focus, can affect the users edit experience, including any javascripts running in the site, but also any external programs that might affect the site. And  these problems may be extremely time consuming to figure out.

Personally, I think the eZ Autosave solution should be modified. Running the preview function only when the editor clicks the Preview tab would make any problems occuring a little bit more predictable. It might be that this solution will be different in the new upcoming admin interface though?

Proudly Developed with from