Can't save

[chrisvanpatten]

Again working on the unstable branch, when I hit save on a new slide, I get the following error:

Uncaught TypeError: Cannot read property 'left' of null interface.min.js:82
  (anonymous function) interface.min.js:82
  f.event.dispatch load-scripts.php:3
  h.handle.i

Is this because I deleted <?php $s->the_x();?> and <?php $s->the_y();?> from the template? (I was locking X/Y so I figured I didn't need them)

[PeterUpfold]

Could you define('SCRIPT_DEBUG', true); in wp_config to get a non-minified error reference? I can probably track this down anyway, but if you have a moment and already have it open...

[chrisvanpatten]

I don't think the uncompressed version is on par with the minified version. Now I see this error:

Uncaught TypeError: Cannot call method 'bind' of undefined /wp/wp-admin/media-upload.php?total-slider-uploader=bgimage&total-slider-slide-group-template=carbonview&total-slider-slide-group-template-location=theme&type=image&post_id=0&tab=library:53

And get this pop-up when I save a slide:

Please correct the following errors with the form.

The supplied background image URL is not a valid URL.

The preview pane doesn't update with the image either, although interestingly the slide thumbnail in the slide navigator on the top does update properly.

Edit: I take it back: I switched to the compressed code and am still getting this error. So now there are two bugs. I'm just ruining everything.

[PeterUpfold]

You're correct, this is to do with templates that do not use the X/Y tags in their PHP file.

I am working on this; here are a few notes to myself that seem appropriate here:

• The selection of the draggable element, as well as the X/Y offets must be conditional on X/Y enabling (or even if that is on, because the template developer may not set the tags properly, and we don't want the whole thing to break).
• interface.js must be prepared for any of those to be null.
• How does this interact with the PHP-based option setting of X/Y positioning? Does that become superfluous in that a developer could simply omit the draggable and draggable parent tags to switch the feature off.

I haven't looked at why you're getting background image issues. That could be a separate thing. Does it happen with other templates?

[chrisvanpatten]

It does appear to be happening with other templates. I can file a separate issue, if you'd like.

[PeterUpfold]

Please do. I'm tracking it down now — there's some weirdness with the new ID-based background URLs and something is casting blank backgrounds (ID '0') to bool(false). That is arriving at the frontend as the string 'false', and that isn't a valid background URL.

[PeterUpfold]

Can you try this commit to see if it resolves this and/or #31?

[PeterUpfold]

I’m going to assume this is the same deal as #31, and close it unless we can reproduce the problem again.