Closed (fixed)
Project:
Site Settings and Labels
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
18 Mar 2017 at 08:59 UTC
Updated:
19 Nov 2017 at 10:28 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
scott_euser commentedThanks 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:
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?
Comment #3
paulmartin84 commented@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
Having that key is not really needed the langcode alone is probally enough.
Comment #4
scott_euser commentedAh 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.
Comment #5
scott_euser commentedI'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
Comment #6
scott_euser commented... and the reupload of the patch
Comment #7
scott_euser commentedThis 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.
Comment #8
paulmartin84 commentedOk, 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.
Comment #9
paulmartin84 commentedOne 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.
Comment #10
paulmartin84 commentedOk spotted one more issue with the original patch. Have added a check to make sure a translation exists before getting it.
Comment #11
scott_euser commentedThanks 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.
Comment #12
scott_euser commentedWas just a simple sort order issue in the tests. Will let the test runner run, otherwise this is good to go.
Comment #14
scott_euser commentedThanks again for your work on this!
Comment #15
paulmartin84 commentedHave spotted one more issue with the above. The clearCach function currently requires a language when it shouldn't. This is probally breaking things badly.
should be
Fixed in the attached patch.
Comment #16
scott_euser commentedFixed 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.
Comment #17
paulmartin84 commentedHi 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.
Comment #18
scott_euser commentedHmmm 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.
Comment #19
paulmartin84 commentedOk thanks, just so you are aware of where the issue is, this fixes it, but seems rather hacky.
Comment #20
paulmartin84 commentedAlso latest updated causes an issue with token function expecting an array.
Comment #21
scott_euser commentedIt 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:
Comment #22
scott_euser commentedFor 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
and set as a base field in the entity:
src/Entity/SiteSettingEntity.php
like fieldset
Comment #23
scott_euser commentedAs this issue will automatically close, could please open a new issue if you still encounter the error? Thanks!
Comment #25
scott_euser commentedI 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.