I ran into a problem where Authcache was causing pages with comments to crash with JavaScript errors.
After reviewing the Authcache Comment module code, I realized that two modules we use cause a conflict: Ajax Comments and Edit Limit.
Both of these are important for us, and we're using ESI to allow a customized comment pane for each authenticated user.
What we essentially needed was to bypass the comment edits being done by Authcache Comment, and retain the comment form changes.
The attached patch adds a authcache_comment_js_override function to determine if there are modules in use that have JavaScript usage which should take precedence over Authcache.
I'm open to looking into another way to address this issue if it is determined to not be the right approach. Please review and let me know your feedback. Thanks.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | authcache-comment_override_options-3055294-7.patch | 6.53 KB | sgdev |
Comments
Comment #2
znerol commentedHey, I'm trying to reproduce this with bartik (standard D7 theme). This is what I did:
With this setup I'm unable to reproduce any JavaScript errors. Am I missing some crucial config, or could it be a theme related issue?
Comment #3
sgdev commentedI don't think it's theme related because there are no issues without Authcache. The setup is a bit more complex than outlined.
Comments are not on the page, they are rendered through Panelizer panes (one for comments displayed in a View, so we can use Infinite Scroll, and a second for the comment form). However I'm fairly certain this would be an issue using Panels too, because the problem I'm seeing is in the Authcache Comment code. Everything with Panels, Page Manager, and Panelizer is working as I would expect.
The Authcache settings for both panes are "per user" and "per page", because of the use of the Edit Limit module. Every user has a window of time to edit their own comments, so it has to be cached for an individual.
There are a number of patches we wrote for both Ajax Comments and Edit Limit to get them to work. It might be easier to see the problem with Edit Limit, since both Authcache Comment and Edit Limit are trying to modify the "edit" link in comments.
Looking at the Ajax Comments patches we're using, I doubt any of them will have an impact on this particular issue. However there are a few relevant ones for Edit Limit:
https://www.drupal.org/project/edit_limit/issues/2416917#comment-13108416
https://www.drupal.org/project/edit_limit/issues/3003429#comment-12896450
https://www.drupal.org/project/edit_limit/issues/2448027#comment-12814782
https://www.drupal.org/project/edit_limit/issues/3015466#comment-12896413
A word of caution that since Edit Limit has not had many patches committed as of late, there is some overlap in the four listed above. If you have any problem applying them, let me know and I can clarify how it needs to be constructed. Thanks.
Comment #4
znerol commentedOk, do you know a way to reproduce the problem with a minimum number of components?
Comment #5
sgdev commentedMy suggestion would be Devel, Authcache, Comments, Edit Limit, Views, Ctools, Panels.
1) Add the Edit Limit patches from comment #3.
2) Configure Edit Limit to allow an authenticated user to edit a comment for X minutes.
3) Create a Views content pane that renders comments for a given node (including comment links).
4) Override node_view template in Panels with a variant that includes node body, the View comments pane, and the Ctools node_comment_form.
5) Configure comments view pane and node_comment_form to have Authcache per user/per page settings. with ESI.
6) Generate nodes and comments.
7) Load page as authenticated user, post comment, and then reload the page.
This will trigger the error between Edit Limit and Authcache Comment, because at that moment both modules are trying to override the comment "edit" link. Might have the same problem not using Panels, but that's the example I have available to me right now.
Comment #6
znerol commentedI took a look at the edit limit module and the linked patches. If there is an edit limit configured for comments, then the backend code appends a string to the edit link with the time remaining for a user to edit his/her comment. The remaining time is calculated using
$time_limit - REQUES_TIME. The frontend code parses this string and starts a timeout. If this timeout is reached the edit link is hidden.The problem with this approach is that for cached pages this timeout will always be the same. Assume there is an edit limit of 10 minutes. If a page was rendered and cached at 12:00, the frontend timeout will expire at 12:10. A subsequent request on 12:05 to the same page will deliver the page from the cache. Since the timeout displayed on the page is relative, the frontend code will set a timeout of 10 minutes and the edit link will only be removed at 12:15. Obviously you only have this problem in the frontend. The access checks in the backend will always work with fresh data. This discrepancy could be detrimental to user experience though.
In combination with all the other issues / patches you encountered, I recommend to just create a custom module which only implements the features for edit link you need in a cache friendly way.
In order to make the frontend code cache aware, you might want to do the following:
There are multiple possibilities to implement the functionality in the backend. Maybe it is more user-friendly to just make the comment edit form read-only and display a message that the timeout has been reached instead of messing with access callbacks. Who knows...
Also since the edit link project is not maintained (last release in 2013) and only has very few users, I'm quite reluctant to accept modifications specific to this module. Also the suggested changes might break existing sites which already have workarounds in place for this kind of problems, thus I tend to reject this patch.
Comment #7
sgdev commentedFair enough and appreciate the feedback, although I think the issue is not quite as detrimental as expressed. Also, the Edit Limit module essentially works the way you describe regardless of caching. If a user edits a comment, the counter is reset back to the original value, giving more time than what is actually allocated.
I think we can avoid any significant issues with some sensible pane caching and the use of the Expire module. One user may have slightly longer than another to edit their comments, but we don't need to be that precise.
I still think there is room for improvement here, and I'd like to propose a different approach that will have no impact on sites already using Authcache. I've reworked the patch to provide an "Override default comment settings" checkbox in the Authcache configuration. This also meets our needs by allowing us to disable the features we don't need (everything other than the comment form alter).
Please review when you have a chance, thanks.
Comment #8
znerol commentedThis is a lot of configuration options for such an edge case. I might include something like that but only if other users require it as well. For now I will postpone the patch.
If you still want to go down this path, then I recommend to alter away the hooks from a custom module. Like this you do not have to maintain a patched version of authcache in your project. The following example should give you some pointers on how to do that (this assumes a custom module called
mymodule). Disclaimer: code written from the top of my head, not tested at all.Edit: Docs on hook_theme_registry_alter and hook_module_implements_alter.
Comment #9
sgdev commentedThat's fine, we use
hook_theme_registry_alterandhook_module_implements_alterin a number of places.Had considered altering away the hooks, but thought I'd share a patch since the options are not entirely related (e.g., replace "new" marker and remove form username have a fairly loose connection to each other).
Thanks for sharing the code, it is correct.