Thread

As many of you have noticed, 2.1.1 shipped with a small bug that is preventing some popular third party add-ons from saving their data on the publish page. Yesterday, we boiled the issue down to a single line of code in our Channel Entries API that was meant to patch up a regression in our autosave code.

In the last 24 hours we’ve been trying to come up with an alternative patch for the autosave bug. Unfortunately the solutions so far involve substantial modifications to our code.

Read More

Who is this sexy new blogger for EllisLab? Thanks for the update.

Autosave disabled, this sounds like a positive change to me. 😊

Autosave disabled, this sounds like a positive change to me. 😊

Agreed. Should be a feature that you switch on instead of having to disable.

so far nothing but annoyance and client confusion with the autosave. it is now disabled in all of my new installations.  /agree with Iain here.

Thanks for the update!

Autosave = disabled sounds perfect. I’ve had to try and explain it to every client who’s using 2.x, it just ends up confusing them.

Client: What’s this autosave message thing?
Me: Urmm, what were you doing before it appeared?
Client: Well I only looked at an entry on the publish page to check something
Me: Did you change anything and not save it?
Client: No, do I need to save every time even though I don’t change anything?
Me: Aaaaargh!

What files are we supposed to update on our installation?

I don’t want to overwrite all my files again just for this quick fix.

Welcome to the forums, adisys -

There are changes in a few places, so you’ll need to follow the build update instructions.

Thank you.

@Kenny M: Do you know why he is sexy? Because he is german! 😛

Autosave disabled! Excellent. (Saves me having to do it)  😜

Autosave is great—so long as it saves something that’s been changed. The problem is, it starts autosaving even if nothing is touched, which happens fairly often in my workflow—I call up and entry to check something or copy something, and autosave kicks in.  Blah.

TTFN
Travis

Sorry, the actual reason I wanted to post was:

Why is this considered a small bug, and

Does this mean that Ellislab does not test new releases with any third-party modules before releasing it?

Because this would probably have been noticed right away, if third-party software compatibility was regularly taken into account in the internal testing process; it’s not like it was an obscure problem with just one add-on. Can you tell us anything about your internal code review process? Might make an interesting blog post.

TTFN
Travis

Sorry, the actual reason I wanted to post was:

Why is this considered a small bug, and

Does this mean that Ellislab does not test new releases with any third-party modules before releasing it?

Because this would probably have been noticed right away, if third-party software compatibility was regularly taken into account in the internal testing process; it’s not like it was an obscure problem with just one add-on. Can you tell us anything about your internal code review process? Might make an interesting blog post.

TTFN
Travis

I actually talk about this on the latest EE Podcast, Travis, including the specific case of this bug.

I was (pleasantly) surprised to read the feedback here regarding the ‘autosave’ feature. I find it confusing (as do my clients) and an irritating interruption when accessing entries. I’d definitely like to see an administrative option to shut this off.

@Kenny M: Do you know why he is sexy? Because he is german!

Flattering :red: .

Why is this considered a small bug

Oops, had my developer hat on. The ‘small bug’ in that first sentence refers to the cause being a single line of code. If we didn’t consider it a major bug we wouldn’t have given it this much priority.

I, too, find the comments regarding autosave rather interesting. There’s clearly room for improvement.