Hi there;
Many thanks for your amazing work!
I have a suggestion to make for future releases of this module.
I found the AJAX and, in general, the JS code to be too strictly tied to Drupal's markup and classes by default.
Some developers (like me) really like to override most (if not all) of Drupal's markup for many reasons. Some people may prefer other CSS naming strategies, some people might find too many nested <div>s, some people just might try to use different HTML5 elements...
My custom theme had many issues with Private Message when I installed it because of this.
For example, the Private Message page is assuming the default field wrappers are present:
container = threadWrapper.find(".private-message-thread-messages:first .field__items:first");
But, in my case, all of the .field and .field__items wrappers were subsituted and thus Ajax wasn't working at all.
I have found a few other issues and all were related to the code being too strictly tied to a given set of classes and markup. This can lead to compatibility problems with almost any theme that chooses to override Drupal's default field, block and page templates.
I think the module would improve if it was less dependant on Drupal's defaults.
In the meantime, maybe it could be a good idea to document the specific classes and markup structures that the module needs in order to work properly. I can lend a hand with that, I think I've found almost all of them.
Comments
Comment #2
idiaz.ronceroComment #3
idiaz.ronceroComment #4
jaypanAjax will always rely on specific classes etc, in order to do Ajax. So there are two options:
1) I can create markup that will force the required classes into the output, irregardless of templates
2) I can create documentation that lists the required classes that need to be added to templates
If you can provide a list of classes that you found were needed for the AJAX to work, I'll be happy to take a look at which of the above options to go with.
Thank you.
Comment #6
jaypanOk, I've gone thorough the JavaScript and tried to find any classes that came from core, replacing them with classes added by this module. Theoretically this should handle the AJAX regardless of theme, though of course it depends on how extreme the themeing is.
Comment #7
idiaz.ronceroMany thanks!!
I think the approach of working with the classes added by the module will work better for us, themers.
Of course, as you said, the themer can still override the module's templates and break things - but then he/she will be able to quickly find and debug the problem, because everything iscontained within the module's realm.
My whole point was this: to make the module more "self-contained", less dependent on third-parties (including Drupal Core), to ease debugging. Many thanks for your work, again.
Comment #9
jaypanFix applied to 8.x-2.x branch.