Fork

Subscribe

Indeed, why forking Ajaxify Regions instead of improving them? How different is Ajax Blocks from the original module?

Excuse me for not answering quickly.
I didn't communicate with the author of Ajaxify Regions, since there was no progress in its development and no issue feedbacks for months at the time when I needed ajax loading of blocks. Ajaxify Regions (even modified for anonymous caching) didn't work properly in my case, and I decided to create a simple module that just works. Of course, Ajaxify Regions was used as a basis.

The motivation for forking was expressed in my CVS application. The main reason is to have a separate simple solution for anonymous caching case (not caching for authenticated users) without dependencies on some authenticated users caching mechanisms.

The modules were quite different before Ajaxify Regions 6.x-1.1 was released.
Ajax Blocks features: per block settings of loading or not via ajax, correct Drupal.behaviors and Drupal.settings manipulation, original block contents wrapped by <noscript> tags, not depending on HTTP_REFERER variable existence, setting $_GET['q'] in ajax handler in order to make any module or theme think the user is visiting the page for which we have to return the blocks. I thought these features were enough to create a separate module.

Ajaxify Regions 6.x-1.1 added some sort of anonymous caching support and selecting the blocks which are to be loaded by ajax. Nevertheless, I'd prefer to have a separate project which focuses on anonymous caching and works correctly in this narrow field.

There's a syntax error on line 239. Just a mistype.

Thank you, @MikeNGarrett. This is fixed in 6.x-1.1 release.

I wish you would have communicated with me as my module is maintained and I would have been more than willing to work with you. I would prefer not to have 2 modules providing relatively identical behavior as its neither good for me nor the community. Send me an email via my contact form and let's figure out if we can avoid duplication.