Twin for this issue raised on ajax_markup: http://drupal.org/node/1147462

ajax_markup has a javascript helper function that looks at the input filter form to determine what filter to apply. When better_format is configured, such that the form is no longer included on the page, that helper function cannot determine the format to apply and falls back to the default.

I think the two project maintainers need together and work out a way for ajax_filter to be able to determine the filter to use.

My suggestion would either be a hidden form or perhaps a specific id on the textarea for ajax_markup to interrogate.

Comments

dragonwize’s picture

dragonwize commented
Status: Active » Closed (works as designed)

BF modifies the form in the same EXACT way, in fact is a straight copy of the code, that core does when there is only 1 available format. So if ajax_markup has an issue with BF in that way then it has a issue with core and so the issue is with ajax_markup not us. The form has to be done that way as well for WYSIWYG module compatibility as it expects it just like core does it.

dunx’s picture

dunx commented

I do think the issue is with ajax_markup. What BF function should ajax_markup call to return the correct format filter to use in any particular case?

dragonwize’s picture

dragonwize commented

What are you trying to do? There should be no need to pull the format. The format will be set when the form is generated.

dunx’s picture

dunx commented

I'm trying to use ajax_markup and better_formats together. Nothing more.

I'm just being pro-active in trying to help the AM maintainer find a solution to the incompatibility.

Don't understand "pull the format". The filter part of the form is missing (either due to BF or core), so whilst the format may be set, AM's current method of looking at form checkboxes can't tell what the format is, so returns 0 and doesn't work it's Ajax magic for previewing the textarea. AM needs to change, not BF.

Is there a BF function that returns the only/default/current format number for a given node type for the current user? That's what AM will need to call if it can't determine the format from the form.

dragonwize’s picture

dragonwize commented

What i am trying to tell you is that this has nothing to do with BF so there is no BF function to call to fix your problem. Even if there was it would not completely fix your issue. If your problem is because there is no fieldset then your problem is with not correctly handing that situation. Drupal core does the same exact thing when the user only has access to one format. Because of this your code will not work in that situation either and hence nothing to do with BF. You can test this by turning off BF, and disabling access to all your formats except your site default, ensure you are testing with a user that does not have admin filters permission obviously.

dunx’s picture

dunx commented

None of this is "my code", but thanks for reply. I think I'll stop trying to be helpful and back off this. Hopefully the maintainer of AM can find a solution.