This is a much needed feature for Login Security. I've done some basic testing with the patch in #6 and this works well. What is needed to get this moving forward?
@zipme_hkt - I have tested using the dev version. Tested with HEAD, GET, and POST for the request method and no issues whatsoever. Thank you for the fast turnaround here.
Raising my hand here as another voice for a release. Looking to have this project available for our client sites. Thanks!
@jurgenhaas - my tests included publish/unpublish not by scheduler and of course publish / unpublish by scheduler. These worked flawlessly. In order to determine if scheduler actually performed the publish, one has to look at the previous (original) values of both publish_on and status and compare to the current values. The logic looks correct to me. The same is true for unpublishing.
@darkodev - have tested and found the update and negation works as expected.
Thank you @ajaysinh from a year and a half ago. Running a D10.3 site and came across this issue recently. I ended up having to patch in 3 places.
I question why core would have a naked call like this. It should be more robust and only throw a warning/error message not a WSOD. Is there a place to report / query on this issue? Thanks.
Would this work both ways - as a way to ban an IP and also unban/unblock an IP? This is an issue I'm running into now. We have clients on dedicated IPs that we would like to ensure never make it into the ban table.
@anish.ir - from my perspective, if an IP is whitelisted, it should not be recorded. I lean towards the second option to completely exclude whitelisted IPs from the Flood Unblock page and the flood table.
I've had a chance to test @darkodev code in #27. The conditions work well for all my test scenarios. The only issue I found was that condition negation does not appear to ever fire. To be honest, I don't know if that is necessary.
I've uploaded my very simple ECA that covers all conditions (publish, unpublish, negation on both).
Just like to add a voice here and say that the patch created by @tyapchyc works as expected.
I agree with @darkodev that we need two conditions for publish/unpublish.
I have a very simplistic ECA model at the moment to test out the various scenarios that would mimic how we use scheduler. The code as found in the MRs doesn't behave as expected. I think part of this has to do with what @darkodev is working on in #20. Looking forward to testing more extensively once there is an update.
Just for clarity, what I'm proposing is not a new event, it's just a condition that will tell the ECA model, if the latest update on an entity had been triggered by scheduler or not. All required events are already available in ECA and would be redundant if we added them here again.
Works for me. As I review what I wrote and thinking about the ECA I've built, a condition makes sense. As you pointed out, required events already exist. I'll be giving your condition plugin a try today and report back.
I would be very interested in better Scheduler integration. For the purposes of the ECA I've created, I've resorted to a series of essentially if-then-else type conditions.
On entity save and validation that it's the proper node/entity that I want. Is Scheduled Open empty?
- If yes, check if published. If yes, check if Scheduled Close exists. If yes - do a bunch of work. The was a scheduled publish.
- If yes, check if published. If no, check if Scheduled Close empty. If yes - do a bunch of work. The was a scheduled unpublish.
- If no, do some other work (housekeeping)
This is a simplified version but you get the idea. Would be nice to have a definitive "Scheduler published/unpublished" type event.
This is an issue as reported by 2 of our clients. I haven't been able to determine the exact process / steps to reproduce based on the information received. I'll update here once I'm able to reproduce.
This is a very much needed feature request. We have had intermittent SMTP server issues (3rd party) and being able to choose a second / alternate would allow us to work around the issues.
Patch in comment #50 works well so far on 4.0.3. Thank you to all who worked on this.
Just discovered this recently. With Drupal 10.1, the default for a request in views using AJAX is no longer POST but GET. You are likely bumping up against a too long URL.
https://www.drupal.org/node/3193798 →
PS: This has created real pain points with a site I'm working on. Not impressed that a big change like that happened in a dot release of Drupal.
Just discovered this recently. With Drupal 10.1, the default for a request in views using AJAX is no longer POST but GET. You are likely bumping up against a too long URL.
https://www.drupal.org/node/3193798 →
PS: This has created real pain points with a site I'm working on. Not impressed that a big change like that happened in a dot release of Drupal.
This issue just occurred for a site we maintain. The IP address in the whitelist was blocked. Removed from the IP address bans list and with just one more failed login attempt, the IP was again banned. The whitelist functionality does not seem to be fully tested.