Audit use of third-party libraries throughout the project

[rnagle]

• Are there any libraries in lib/ that we should update?
• Are there any libraries in lib/ that are unused and should be removed?
• Are we using javascript libraries that we should update?
• Are there any javascript libraries that are unused and should be removed?
• Look into updates and/or additions to our Fontello package.

[meredithinn]

First pass -- I found the following:

Clean contact

Navis media credit

Related issues

Navis Slideshow gallery image size

Clean contact settings

Maybe @tothebeat would have a look with me to see if I missed anything.

[nrrb]

Contents of /lib

Definitely Used

• /lib/lessc.inc.php - lessphp v0.3.9, LESS CSS compiler used in /inc/custom-less-variables.php
• /lib/class-tgm-plugin-activation.php - TGM Plugin Activation v2.3.6 used in /inc/plugin-init.php
• /lib/options-framework/options-framework.php - Options Framework used extensively for theme options in /options.php

Questionable how much these are used

• /lib/clean-contact/clean_contact.php - our customized version of Clean Contact plugin this appears to register a shortcode which is not used directly in the Largo code but is provided to the end users as described in this documentation in /docs/users/contactforms.rst.
• /lib/navis-media-credit/navis-media-credit.php - Our version of Navis Media Credit from the original Argo project, used in another library navis-slideshows, not sure if this is usable by end users directly
• /lib/navis-slideshows/navis-slideshows.php - Our version of Navis Slideshows from the original Argo project, this changes the way that galleries are displayed in a post. I'm having a hard time finding an example of its use on a member site.

[rnagle]

Building on @tothebeat's and @meredithinn's comments:

No updates for:

• Clean Contact
• Navis Media Credit
  • Argo Project plugin
• Navis Slideshows:
  • Argo Project plugin
  • No recent updates
  • Highly modified by us

Updates are available for:

• lessphp:
  • Latest version is 0.4 (we're behind by one point release)
  • This has been lightly modified by us to be able to submit Largo, which haven't done yet.
• TGM Plugin Activation:
  • Latest version is 2.4.2 (we're behind by a few releases)
  • Tthis has been modified by us
• Options Framework
  • Latest version is 1.8.4 (we're using 1.4)
  • Some modifications by us

To absolve ourselves of this chore, I think we should completely absorb some of these libraries into Largo, linking/crediting the original project where appropriate (or required). This should be fine for the libs that have no updates upstream.

The libraries that are under active development AND which we have modified for use in Largo are another story.

In the case of the lessphp lib, we'll generally have to modify any release to use WP_Filesystem instead of core PHP functions for accessing and modifying the filesystem, since this is a requirement if we want to submit the theme to WordPress. Since we've already modified the version we're currently using, let's stick with that for now. It's not too far out of date, anyway. Maybe we should consider creating a fork of the project, modifying it to meet all of WordPress' requirements for submitting themes and plugins to the directory.

TGM Plugin Activation seems to be working fine for our purposes. I'm not sure we have needs that the newer version addresses. None of the updates appear to address security concerns.

It would be nice to update the Options Framework library, but it saw a major refactor in version 1.7. I tried updating locally and while the options page appeared to render, it's unclear if saving/updating works. Also, updating results in a broken layout on the options page (i.e. missing or moved css files). Bottom line is, this will require some work.

Does anyone have strong feelings about any of this? I'd like to create new tickets to address the issues with individual components as outlined above.

[rnagle]

As for javascript libraries:

• select2:
  • We're using select2 for Largo's custom post types functionality, where we allow the user to select an icon to associate with a custom post type.
  • We're using version 3.4.8 and the most recent version is 3.5.2. There are no release notes readily available explaining the benefits of upgrading. The library seems to work fine for our purposes so I think we're OK to leave it as-is.
• modernizr
  • We're using a customized version 2.6.3 where the most recent release is 2.8.3.
  • I don't think there's any pressing need for us to upgrade this library.
  • It would be nice to have documented what a custom build of modernizr for Largo is comprised of. This would make updating/upgrading easier in the future.
• jquery.idTabs.js
  • We're using version 3.0 which is recent as of 2010.
  • Considering what we're using it for, we could write our own javascript, drop a dependency and save some bandwidth by cutting out the features that we don't use.
  • Used with the Largo Explore Related widget
  • This should take an afternoon (or less) of refactoring

Think that covers it. Same as with PHP libs -- any strong feelings here?

[benlk]

Just a small note on jquery.idTabs.js - if we don't drop it, we should consider renaming it to jquery-idTabs.js so that the uglify task will name the minified version as jquery-idTabs.min.js instead of jquery.min.js. Uglify chops filenames at the first period, not at the last.

[aschweigert]

For the PHP stuff, I think forking lessphp to make it wordpress compatible makes sense, updating the plugin framework doesn't seem particularly urgent to me (although there's a permissions issue I need to open a ticket for that we need to try to hunt down) and for the options framework....rather than update that I'm wondering if we should just really get serious about using the customizer since WP is really trying to push people in that direction. Seems like that would naturally be part of 0.6 anyway.

For the JS stuff, all of the above seems fine to me. I would prefer to get up to the current version for all of these, with the possible exception of the tabs thing which I think we could definitely refactor and remove the dependency.

[rnagle]

Created several new issues based on the audit. Thanks for the help, everyone!