Good to know. Thank you very much!
Well, I was struggling with caching too, and stumbled upon this issue. Only this issue is far behind the current version of the module. I did some fiddling around, but did not get a proper way to merge this code into the current version. So I created a very basic implementation of the current workbox script. It is lacking nuance, and is rather crude. But I think it is working for now. Maybe a starting point to work on going forward.
Great! Thanx for sharing it. I will link it on my project page, and give it a try!
Here is the above patch for version 2.2.6. Since the change log shows de js files are not modified, I just repatched the js files.
I also tried to add a hook_ENTITY_TYPE_build_defaults_alter (hook_product_variation_build_defaults_alter) to add the user.role context. The strange thing is that the cache context is added, but I think that later in the process somewhare a call to getCacheContexts is done, and then the original cache context is restored. But I did not have the time to confirm my feeling.
Thanx @kaszarobert. Ik think you have a fair point here. Thinking about it, a hook like yours could be added to the module, only we don't use the module but it is integrated via google tag manager. So than we should incorporate it in a custom submodule for ourselves I think.
This is the patch. I know it is not to be comitted to the module this way, but for reference if someone needs it.
joshahubbers → created an issue.
This is the patch. I know it is not to be comitted to the module this way, but for reference if someone needs it.
joshahubbers → created an issue.
Another fix is to add the 'user.roles' cache context to the productVariation entity:
File: commerce/modules/product/src/Entity/ProductVariation.php
/**
* {@inheritdoc}
*/
public function getCacheContexts() {
return Cache::mergeContexts(parent::getCacheContexts(), ['store', 'user.roles']);
}I will have a look at the commerce issue queue to check if there is an issue for this.
We added 'user.roles' in our services.yml, like this:
required_cache_contexts: ['languages:language_interface', 'theme', 'user.permissions', 'user.roles']
But I think this should be added as a cache context explicitly to the display as a better fix.
We experience the same problem, but prices are cached across users. So if a user with a discount opens the page first, a user without the discount will also see the discounted price also.
Thanx Johan! Fixed and committed.
Great. Thank you for the fix and your effort.
Hi Timo,
I approved your suggestion. Let's wait untill the new po has been generated and check if it is complete then.
Thanks for your help!
This is a duplicate of 🐛 rh-node.js error: $action.next(...).textContent is not a function Fixed . That one has been committed.
joshahubbers → created an issue.
I am having schema issues also with the plugins...
joshahubbers → made their first commit to this issue’s fork.
I removed the module from this commit, as I think you mostly want to customize what exactly happens there, and not everything is generic enough.
I add the module as zip for reference.
Example module →
So what this patch does:
- Add hook to expand the service worker
What it does not do (see how to do it in the example module):
- Add new submodule for the notifications (see zip file for an example)
- The firebase service worker has to come from a specific url: /firebase-messaging-sw.js. The url is altered with a route to serve the service worker from this location.
- When a user accepts the push messages, the token is saved to the database.
Yes, great. Now only test-coverage is missing. ;-)
Back to working on this... please mind this is work in progress. F.e. in the current patch we show the token of the browser in the frontend to allow us to easily send test messages. ;-) Just so you know the current status.
Sorry, I know I am a knit-wit... but "enabled" suggests the variable enables the entire functionality. But it enables/disables the protection of 404, 403 and front pages. Maybe rename that to "protect_404_403_front"? Than it is obvious what the setting does...
joshahubbers → created an issue.
joshahubbers → created an issue.
🐛 Upload app icon results in error Active is included in this patch
Hi @divyansh.gupta,
you said in #7:
So as per your suggestions i will work and create a option to enable/disable this feature in settings form.
I am missing that in this branch?
You can always open the "Diff"-link in the mr above and save that as a .patch or .diff. This file you can use in composer. But for your convenience I attach it here.
I think this should be closed in favour of the other ticket. The idea was that you could use your own local scripts if you would like that (I think ;-) ).
The patch file for use in composer
joshahubbers → created an issue.
Patch file for composer
joshahubbers → created an issue.
Patch version for composer.
joshahubbers → created an issue.
Patch version to include in composer install ;-).
joshahubbers → created an issue.
See also 💬 How is this different from PWA module? Active
Is this a duplicate of 💬 How is this different from PWA module? Active
joshahubbers → created an issue.
Thank you! That's nice.
Maybe the check for unpublished should be a seperate ticket because it is new global functionality, don't you think? If so than I can create a new issue for that?
Ah great, I think I was looking at another version of the code ;-)
Working fine anyway. Thanx!
joshahubbers → created an issue.
I think use Drupal\Component\Utility\Html; should be added to the top of the file too?
This is a duplicate of 🐛 The module adds white space at the top of the olivero theme Needs review I think.
I agree that a setting should be preferrable to prevent unexpected functionality.
What I was wondering: the normal work of this module is a checkbox at the node page (I did not live test the module, but that's what I got from the documentation, correct me if I'm wrong). If this is the point, the checkbox should be checked and grayed out on the page that is set as homepage, 404 and 403 by default to keep consistency with the normal working way of this module.
A last point: is unpublishing of the page also prevented for these modules?
When these points are fixed, I think we can deprecate the prevent_homepage_deletion module in favour of this one.
(I add the patch anyway to include in composer)
I see this is already fixed in the develop branch. ;-) Sorry for reporting.
joshahubbers → created an issue.
joshahubbers → created an issue.
Patch for the issue.
joshahubbers → created an issue.
I think this is a duplicate of 🐛 Undefined array key "name" RTBC , which is done...
joshahubbers → created an issue.
joshahubbers → created an issue.
Thank you very much for all your time!
joshahubbers → created an issue.
I decided to create a simple dashboard that collects the reports of sites using Site Guardian and displays them in a view: .
Hi Heikkiy,
When I look at the table here https://www.drupal.org/docs/distributions/degov/semantic-versioning-model → it suggests:
0.0.x = patch version for bugfix
0.x.0 = minor version update with new features that do not break functionality
x.0.0 = major, new features, breaking backwards compatability.
Well, this upgrade doesn't really add new functionality, so I think your decision to go to 1.0.4 is totally fine ;-).
Thanks for your collaboration!
I required 1.7 explicidly in my local composer. But than you have to be sure not to apply the patch in 🐛 Entity Embed fails to install after Embed module update Active because that will break the updb.
JoshaHubbers → created an issue.
These strings only exists in Dutch, so they won't have to be translated.
@sclsweb: I created a new release with this fix.
@PrabuEla
You did not set a front page, the whole purpose of this module. So you never came to the check.
I added a fix for the issue so the message is
* not shown for anonymous users
* only shown at the */delete url or if the action "node_delete_action" is present
JoshaHubbers → made their first commit to this issue’s fork.
I had the same reasoning as you. If someone is on 8.x, then I don't think they will be doing minor modules updates either...
Fine by me! Lets release.
Hm, I did add your suggestion to the module, but accidently committed it in the dev branch in stead of in the issue fork. If you want to test the implementation in the dev-branch, it would be great...
Did you use this in combination with workflows?
Hm, nice, I will have a look at inserting it in the module and write some tests for it.
This is a tricky one indeed. It is not very hard to intercept the form and prevent the published setting being set to false, but how will this behave in automated workflows? I have to think about this a little.