Problem/Motivation

As long as Checklist API is used to store status data should use State API instead of Configuration API as documented:
- https://www.drupal.org/docs/8/api/state-api/overview
- https://www.drupal.org/docs/8/api/configuration-api/overview-of-configur...

Also, this appears as a problem when exporting configuration the current checklist status is added as configuration and the site importing if loading it, generating incongruences when the checklist has the status of the site.

Proposed resolution

Use State API instead of configuration one.

Comments

quiron created an issue. See original summary.

traviscarden’s picture

Title: Checklist should use State API instead of Configuration API to store the status information. » Use State API instead of Configuration API to store checklist progress
Category: Bug report » Task

I agree. We'll need an upgrade path, of course. I won't be able to get to this right away. Patches welcome.

quiron’s picture

Maybe I can work on it.

The first question to achieve is how to translate the configuration object structure to a key-value storage like the State API.

  1. One approach is expose each value to be stored as a State variable, by namespacing it, like:
    checklist.MY_CHECKLIST.changed
    checklist.MY_CHECKLIST.changed_by
    checklist.MY_CHECKLIST.completed_items
    checklist.MY_CHECKLIST.item_name_1.complated
    checklist.MY_CHECKLIST.item_name_1.uid
    checklist.MY_CHECKLIST.item_name_2.complated
    checklist.MY_CHECKLIST.item_name_2.uid
    
  2. Other approach is keep only one key, like checklist.MY_CHECKLIST and serialize the array.

@TravisCarden what makes more sense to you?

thanks.

traviscarden’s picture

I would take approach #2. The State API should serialize the array for you. The storage system should be essentially swappable in \Drupal\checklistapi\ChecklistapiChecklist::saveProgress(). Thanks!

quiron’s picture

StatusFileSize
new3.85 KB

Here it is an initial approximation with serialization.

This was tested and working in my environment

chr.fritsch’s picture

Status: Active » Needs review
mlncn’s picture

chr.fritch very nice!

+1 to this patch.

The declaration of the PROGRESS_CONFIG_KEY constant is obsolete after this patch but it can't actually be removed because then the update would break— maybe it would make sense to hard-code the constant value in the update hook just so the constant could be cleaned up?

I would suggest that the $config variable be changed to $state or $progress for easy comprehension of the code but that's also minor / not really the role of this patch.

Hi Travis, have you had a chance to review this?

I came here to file the same issue, and am glad to see it filed, encouraged, and with a patch! As far as upgrade path i was wondering if it wouldn't be too much burden for Checklist API to support *both* config and states checklists (for instance SEO Checklist using config makes sense as its one set of tasks to do across dev and live— but this patch already has the upgrade path!

traviscarden’s picture

Thanks, all! @mlncn, I like the idea of supporting both config and state for progress storage. I'll make it a setting in hook_checklistapi_checklist_info() so module authors can choose which they want and developers can override it with hook_checklistapi_checklist_info_alter(). I'll make it optional for backward compatibility and default it to config. Let me see what I can whip up.

traviscarden’s picture

Title: Use State API instead of Configuration API to store checklist progress » Add the ability to use State API instead of Configuration API to store checklist progress
Category: Task » Feature request
StatusFileSize
new11.61 KB

Let's see what the tests say about this.

traviscarden’s picture

StatusFileSize
new11.6 KB

Oops. Accidentally used a PHP 7.1 only feature.

  • TravisCarden committed 76f7a15 on 8.x-1.x
    Issue #2944103 by quiron, TravisCarden: Use State API instead of...
traviscarden’s picture

Status: Needs review » Fixed

All right, there you go! Module maintainers can now choose their storage backend by setting the "#storage" value in their checklist definition. Allowed values are "config" and "state". Default is "config". Developers can override a checklist's storage setting using hook_checklistapi_checklist_info_alter() as in the below example:

function example_checklistapi_checklist_info_alter(array &$definitions) {
  $definitions['seo_checklist']['#storage'] = 'state';
}

Checklist API Example module contains an example of moving saved progress from one backend to the other in an update hook:

function checklistapiexample_update_8101() {
  $checklist_id = 'example_checklist';

  // Get saved progress from old config storage.
  /** @var \Drupal\checklistapi\Storage\ConfigStorage $old_config_storage */
  $old_config_storage = \Drupal::service('checklistapi_storage.config');
  $saved_progress = $old_config_storage->setChecklistId($checklist_id)
    ->getSavedProgress();

  // Copy saved progress to new state storage.
  /** @var \Drupal\checklistapi\Storage\StateStorage $new_state_storage */
  $new_state_storage = \Drupal::service('checklistapi_storage.state');
  $new_state_storage->setChecklistId($checklist_id)
    ->setSavedProgress($saved_progress);

  // Delete old config storage.
  $old_config_storage->deleteSavedProgress();
}

I'll cut a release with the new feature soon. Feedback welcome. Thanks for the suggestion and the help!

Status: Fixed » Closed (fixed)

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