[closed] Moving Rules in Containers errors on 2nd time

Has anyone else had issues where if you have a bunch of rules in a container and if you go to move the order, on the second move, the order is a GET not a POST and ends up in the URL.

In the past I’d notices it mostly if the rule was a gmap, which I thought all the javascript would cause it, but I’ve just come across it with a bunch of 4 rich text boxes containing only simple tables.

The console tells me:

Uncaught TypeError: Cannot read property 'add' of undefined

and then the next move fails. Turns out that gritter wasn’t being registered properly and hence a js fail. The id needs to be changed in registerLibraries.cfc from gritter to fc-gritter.

Now the gritter works when you move an item and also all these cool tool tips appear that I’ve never seen before. But unfortunately on the second move it still throws a GET instead of a POST. This time with a bunch of these in the console:

Uncaught ReferenceError: $j is not defined

Any suggestions?
I’m on FC7.06/railo 4.

I’d guess that the GET request you’re seeing is actually re-loading some JavaScript (you might see it if you view the source of the response) and that’s what’s causing the problems. I have seen this if the execute.cfm webskin of a publishing rule loads JS within it - the solution could be to load it in the parent page instead if possible.

Is this a custom publishing rule, or something from core / a plugin?

Hi Justin,
Its just the bog standard rich text rule from core. I’ll have a play
tomorrow and see what I can find.

Phillip Rasmussen
(sent by mobile phone)

Looks like it was the event binding that was the issue, along with the wrong id being loaded for the gritter. I added a ticket and just committed a fix to p700. Thanks Phillip :slight_smile:


1 Like

Thanks Justin, That works well :smile:
Don’t forget to also:

I did the opposite in that case; lots of places already use “gritter” and
that one case was the odd one out using “fc-gritter” :slight_smile:

1 Like