I'm not sure if there is anything else that needs to be done, there very most likely is. The attached patch enables you to add translations to site settings fields and then the twig variables will display the correct values using the current site language.

Comments

paulmartin84 created an issue. See original summary.

scott_euser’s picture

Thanks for the effort you have put into this, this seems like a useful feature to have in place!
I haven't had time yet to test, but just a quick what scanning over the patch:

+++ b/site_settings.module
@@ -8,9 +8,16 @@
+const SITE_SETTINGS_CACHE_CID = 'settings';

I'm nervous that this might be used elsewhere by another module, core etc. It doesn't work to keep it prefixed by the module name?

paulmartin84’s picture

@scott_euser Hi, you will see I also added a cache bin, SITE_SETTINGS_CACHE_BIN = 'site_settings'; so all site settings are in their own isolated cache. This allows us to delete all of them easily in one go. Each language is stored in that bin with the key settings:langcode

\Drupal::cache(SITE_SETTINGS_CACHE_BIN)->get(SITE_SETTINGS_CACHE_CID . ':' . $langcode))

Having that key is not really needed the langcode alone is probally enough.

scott_euser’s picture

Ah right I see, that makes sense. I think good to still keep the key (as you have it in your patch) in case we want to eventually use the bin for something else as well.

scott_euser’s picture

Status: Needs review » Needs work

I've reuploaded this with no changes just to make it apply to the current state of the dev branch. This looks good but needs drush entity-updates in order to work. This therefore needs a hook update so existing installations don't break: https://www.drupal.org/docs/8/api/update-api/updating-entities-and-field...

This set of examples might be helpful
https://www.drupal.org/node/2554097

scott_euser’s picture

StatusFileSize
new5.63 KB

... and the reupload of the patch

scott_euser’s picture

Status: Needs work » Postponed

This is unfortunately not something high up on my to do list for now, if someone is willing to contribute a patch to get it there I would be happy to implement, but otherwise I am parking this for now.

paulmartin84’s picture

Version: 8.x-1.8 » 8.x-1.x-dev
Status: Postponed » Needs review
StatusFileSize
new7.51 KB

Ok, I've had a go at trying to maintain an update path. I couldn't find another example of a module that has had to add a data_table at a later date. So hopefully this is the correct approach.

paulmartin84’s picture

One issue with the last patch, is if you haven't already run update 8003 then when you try to update with this, you get an error as the data table has already been mentioned in the code. This ensures that if you haven't run 8003 then 8004 will run first.

If we really want a translatable site setting module the sooner this gets in the better as further changes/update hooks will only complicate this further.

paulmartin84’s picture

Ok spotted one more issue with the original patch. Have added a check to make sure a translation exists before getting it.

scott_euser’s picture

Thanks for your work on this - I'll try to take a look sometime in the upcoming week. Will need to get this passing the tests as it needs to have backwards compatibility.

scott_euser’s picture

Status: Needs review » Reviewed & tested by the community
StatusFileSize
new41.8 KB
new23.46 KB

Was just a simple sort order issue in the tests. Will let the test runner run, otherwise this is good to go.

  • scott_euser committed 91ae60a on 8.x-1.x
    Issue #2861764 by paulmartin84, scott_euser: Add multilingual support...
scott_euser’s picture

Status: Reviewed & tested by the community » Fixed

Thanks again for your work on this!

paulmartin84’s picture

Status: Fixed » Needs review
StatusFileSize
new41.79 KB

Have spotted one more issue with the above. The clearCach function currently requires a language when it shouldn't. This is probally breaking things badly.

public function clearCache($langcode) {

should be

public function clearCache() {

Fixed in the attached patch.

scott_euser’s picture

Status: Needs review » Fixed

Fixed on dev (was not released).

Can you use a .patch file so it gets unit tested and add interdiffs please next time.
Your patch did not apply and tests didn't run on it.

paulmartin84’s picture

Hi Scott, sorry about that .txt extension, not too sure what I did there. I am having some problems when creating new values for settings.
Your latest fixes to the module have broken things quite badly for me. There are now lots of `user_id` keys in every settings array and they are not getting removed as they are not base fields.

scott_euser’s picture

Hmmm was the other way around for me, was getting fatal errors from the multilingual without multilingual enabled.

I'll take a look in the morning.

Need to keep getting further test coverage in, tried to get a bunch of test coverage in this morning but it wouldn't yet cover repeated saving.

paulmartin84’s picture

StatusFileSize
new681 bytes

Ok thanks, just so you are aware of where the issue is, this fixes it, but seems rather hacky.

paulmartin84’s picture

StatusFileSize
new1.17 KB

Also latest updated causes an issue with token function expecting an array.

scott_euser’s picture

It appears the token had an incorrect type. Your change made it fail coding standards unfortunately as coding standards expects type casting which is why array made it in. I've switched that to string:

 /**
  * Convert the token key into a more readable label.
  *
- * @param array $key
+ * @param string $key
  *   The token key.
  *
  * @return string
  *   A more readable label.
  */
-function _site_settings_token_label(array $key) {
+function _site_settings_token_label($key) {
   $label = str_replace(['--', '-', '_'], ' ', $key);
   $label = rtrim($label);
   $label = ucwords($label);
scott_euser’s picture

For the other issue, I can't reproduce it. Have you run 'drush updb'? There was a pending entity update.
As far as I can see from the code, user_id behaves exactly like fieldset - based field save on entity form:

src/Form/SiteSettingEntityForm.php

    // Save the entity.
    $entity = $this->entity;
    $entity->set('fieldset', $values['fieldset']);
    $entity->set('user_id', $values['user_id'][0]['target_id']);
    $entity->save();

and set as a base field in the entity:
src/Entity/SiteSettingEntity.php

    $fields['user_id'] = BaseFieldDefinition::create('entity_reference')
      ->setLabel(t('Authored by'))
      ->setDescription(t('The user ID of author of the Site Setting entity.'))
      ->setRevisionable(TRUE)
      ->setSetting('target_type', 'user')
      ->setTranslatable(TRUE)
      ->setDefaultValue('')
      ->setDisplayOptions('view', [
        'label' => 'hidden',
        'type' => 'author',
        'weight' => 0,
      ])
      ->setDisplayOptions('form', [
        'type' => 'entity_reference_autocomplete',
        'weight' => 5,
        'settings' => [
          'match_operator' => 'CONTAINS',
          'size' => '60',
          'autocomplete_type' => 'tags',
          'placeholder' => '',
        ],
      ])
      ->setDisplayConfigurable('form', TRUE)
      ->setDisplayConfigurable('view', TRUE);

like fieldset

    $fields['fieldset'] = BaseFieldDefinition::create('string')
      ->setLabel(t('Fieldset'))
      ->setDescription(t('The fieldset of the Site Setting entity.'))
      ->setSettings([
        'max_length' => 50,
        'text_processing' => 0,
      ])
      ->setDefaultValue('')
      ->setDisplayOptions('view', [
        'label' => 'above',
        'type' => 'string',
        'weight' => -4,
      ])
      ->setDisplayOptions('form', [
        'type' => 'string_textfield',
        'weight' => -4,
      ])
      ->setDisplayConfigurable('form', TRUE)
      ->setDisplayConfigurable('view', TRUE);
scott_euser’s picture

As this issue will automatically close, could please open a new issue if you still encounter the error? Thanks!

Status: Fixed » Closed (fixed)

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

scott_euser’s picture

I know this is closed, but potential change coming in https://www.drupal.org/project/site_settings/issues/2924674 and want to give others using this on a multilingual site a chance to review. Either way I'll review and try to ensure adequate test coverage.