If the values are cached (per-node) they can be retrieved in views as well, so we can easily implement #376273: Taxonomy/Views Support. See also #371479: Content Completeness calculation on a per-node basis next to the per-type basis.

Comments

hunvreus’s picture

hunvreus commented

I am about to commit the code for the updated version of content complete (probably sometimes tomorrow), and felt like explaining how the caching works.

First, we need caching for the obvious reason that computing completeness is made by checking on each field of the node and if we are to use this in, say, a view, then we can't afford to compute every time we want to display the value. The table that used to store the settings will host this caching, in the meantime we move the settings that were stored in this table (which fields for which content types are part of the completeness pool) to the variable table through variable_get and variable_set (the usual way of storing configuration in Drupal).

Now, we can obviously update that cache on a per node basis when creating, deleting and editing nodes, however we have a few cases to take into account;

- people already have a running site and install the site, activating completeness for nodes that already exist,
- the administrator change the settings for a content type (adding a field for example to complete)
- another module did some bulk update without using edit/delete/create regular workflow, thus not updating the cache

In each of these cases, we need to be able to rebuild at least part of the cache, either automatically (when changing the content_complete settings for a content type, we clear the cache for all nodes of that type) or manually (something like the "Rebuild index" button in the search settings). That's why we have a cron updating the cache for all nodes that don't have a cache yet (and have content_complete enabled).

pvhee’s picture

pvhee commented
Status: Active » Fixed

Thanks hunvreus, your code went into the latest 1.2 release!

pvhee’s picture

pvhee commented

In the 1.2 release, note that the update at cron has been replaced by a rebuild cache function (using Batch API). In general, cache needs to be rebuilt only when the administrator changes settings of the module (as desribed by hunvreus above). Therefore, it is easier to rebuild the cache all at once using Batch API than to have various cron jobs run in order to complete everything (just imagine a site with 10.000+ nodes that all need their caches rebuilt, you might need a lot of cron runs to complete).

hunvreus’s picture

hunvreus commented

Great; now let's talk roadmap.

From what we discussed, the idea from there would be to prepare the two following things;

- Improve the sequencing for the fields to be completed; proposing users to sort the order in which fields should be filled in (thus removing the need for trying to guess what is supposed to be the next field to fill in)
- Add a weight to fields; some fields may be more important than others when computing the completion percentage
- Prepare eventually the merging with Complete

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.