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.
Fixed in the new release.
JoshaHubbers → made their first commit to this issue’s fork.
Excuse me... I just realize that I did not update to the latest version of 10.2. While updating to the latest version, this patch had to be removed again. Sorry for the confusion.
Patch with this change for 4.23. This fix is not in that release and my drush updb got stuck on this when upgrading to 10.2.
So no new development, just the patch file to use in composer.json.
Hi @HeikkiY.
Sorry for my absense. Had a very busy time lately. Switched work and also personally. I will look at your comments as soon as possible, but some quick responses:
* I run the tests with the ddev tooling
* git instructions are updated automatically on d.org normally as soon as one starts committing in the repo. Strange that it doesn't here.
* I agree that we can start a new major branch, and drop support for older Drupal versions. I would suggest only supporting the currently supported versions in the new branch
Maybe a good start to commit the fixes in this MR, because most of the issues are solved. And than we move to a new 2.x branch to start working on a new release?
Done:
* gitlab ci added
* composer.json added
* .gitignore added
* cspell words list added
* test fixted
* most phpstan fixes. Some phpstan errors are coming from hook-declarations that are inherited from core.
Done:
* gitlab ci added
* composer.json added
* .gitignore added
* cspell words list added
* test fixted
Todo:
* phpstan fixes
Oops, pushed the gitlab-ci.yml file directly to the 1.0.x branch. But fixes will be done in this MR.
JoshaHubbers → created an issue.
Added two co-maintainers. Welcome! Looking forward to your improvements.
* Added a catch to handle responses other than 200
* Added some catches to prevent php warnings for not sending a string into json_decode
JoshaHubbers → created an issue.