Consider moving htmLawed.php into libraries

Thanks for this suggestion. I have not used the Libraries module but will look into its API to see how much work will be involved if this idea is implemented.

(As such, with the current htmLawed module, to use the version of htmLawed library with HTML5 support, one only needs to replace the htmLawed.php file in the module).

It seems that implementing the suggestion should be easy, with code like:

if (module_exists('libraries')) {
  // Support Libraries API - http://drupal.org/project/libraries
  $module_path = libraries_get_path('htmLawed');
  include_once ("$module_path/htmLawed.php");
}
else {
  $module_path = drupal_get_path('module', 'htmLawed');
  include_once ("$module_path/htmLawed/htmLawed.php");
}

However, I am not sure if giving priority to the external htmLawed library over the one provided in the htmLawed module is a good idea. E.g., the external library may be an older version. (I intend to continue to bundle the htmLawed library within the module in future releases of the htmLawed module.)

One way around this is to compare the library versions and use the latest one. But, it is possible that the Drupal administrator actually wants to use an older version of the library. To get around this, the htmLawed module itself may provide a configurable option that allows the Drupal administrator to choose between the external library and the bundled library.

Such fine-tunings will require mode coding, and also make the htmLawed module give special consideration to the Libraries module.

I am therefore still thinking about whether all this is worth it, when a Drupal administrator can simply replace the htmLawed.php file in the htmLawed module when they want to use an htmLawed library of their chosen version. May be one should wait for Libraries to become a core Drupal module.

I will appreciate any feedback on these thoughts.

+1 as a security minded module, the library should absolutely be able to be updated independently from the module. This allows the sites to be able to have security upgrades outside of the module development cycle. This is important especially since this module dev cycle is not keeping up with htmlLawed library dev cycle.

As I wrote earlier, updating the htmLawed library is as simple as replacing the file for it in the htmLawed module. I am not familiar with the libraries API, but if htmLawed library is indeed separated from the htmLawed module as suggested, wouldn't updating the htmLawed library still require manual work -- replacing the htmLawed library file but now at a different location? If so, how will things be any better? I maintain both the htmLawed library and the htmLawed module and make sure that they remain compatibale; i.e., the library can be updated without updating the primary module files.

...updating the htmLawed library is as simple as replacing the file for it in the htmLawed module. I am not familiar with the [Libraries] API, but if htmLawed library is indeed separated from the htmLawed module as suggested, wouldn't updating the htmLawed library still require manual work...?

Yes, replacing the file will require more work (unless you use Drush make, whichmany site builders do). However, you seem to be ignoring the fact that the module may need to be updated independent of the library or visa versa (e.g., using the HTML5-compatible version of htmLawed library).

replacing the htmLawed library file but now at a different location? If so, how will things be any better?

Should the module be updated by another systems administrator who is unaware that a previous one has replaced that file, it will be overwritten and may break a site. Perhaps a yound geveloper decides to click the "Update modules" button and overwrites the cusomt library. While a developer should read the documentation and memorize all of it, that's not practical in all instances. Libraries API integration is, however, practical in every circumstance.

I maintain both the htmLawed library and the htmLawed module and make sure that they remain [compatible]; i.e., the library can be updated without updating the primary module files.

That's great news! Now, to reiterate what two others, an now myself, have said: The module cannot be updated without also replacing the module's bundled library, as per the Drupal spec. This means if a developer has replaced the library in the module folder with a specialized htmLawed library (such as the HTML5 version) everytime a new release of this module comes out, it must be re-downloaded and uploaded. This creates probelms and headaches easily solved by a hook you've already written.

I am not sure if giving priority to the external htmLawed library over the one provided in the htmLawed module is a good idea. E.g., the external library may be an older version. (I intend to continue to bundle the htmLawed library within the module in future releases of the htmLawed module.)

It shouldn't matter what you want another developer to do with their site, if they want to use an old version, for any reason, your module shouldn't interfere with their ability to do so. The file in the library folder should take precedence, always, as it is the deliberate choice made by the site developer.

Finally, I now hope you can see that the bundled library is actually an impediment at the point this issue is relevant to a user of your module. I implore you to make the Libraries API a valid option for htmLawed library use. I like both your module and your library and this is my only impediement to implimenting it on future client sites.

Curtapedia, thanks for your explanations. I have now released version 3.4 of the module (for Drupal 7) that permits operability of the module through the Libraries (API 2.x) module.

The htmLawed library's files (htmLawed.php and htmLawed_README.htm) need to be in a directory named 'htmLawed' in the Library module's 'libraries' directory. The htmLawed library specified through the Libraries module gets precedence over the default htmLawed library that is bundled in the download for the htmLawed module.