🇺🇸United States @philsward

philsward → created an issue.

Even after patch #20 applied to latest dev, I'm still receiving the error:

Deprecated: Required parameter $output_plain_text follows optional parameter $level in /sites/all/modules/contrib/httprl/httprl.module on line 2861

But... specifically on page: /admin/config/development/logging

I haven't poked around to other pages to find any other offenders, however the logging config page definitely throws it for me.

Therefore I think that cloning files should be optional and off by default.

Agreed, however, how can we deal with the presence of fielfield_paths which I believe is the offending culprit for the majority of use-cases?

HTTPRL was causing the issue for me.

I disabled it, fixed the version in the bootstrap theme and re-enabled it.

I'm going to say that #6 needs some work.

I honestly don't know if it works (yet) because I'm writing this AFTER finding the new Clone Files option.

But...

If the patch is applied and the option is set to No (the default option after applying the patch), presumably, the patch doesn't address the initial shortcomings of the core of the issue.

If a node is cloned for example and has images, the images are "moved" from the original to the clone on saving the clone.

If the original node is then edited and saved, all of the images "move" from the clone back to the original.

Ideally, the option of "No" should take into consideration any files and then erase all references to those files on clone save instead of carrying them over to the clone for the two nodes to then play tug-of-war on which one get's to house the images.

I'm using filefield_paths with "active updating" turned on which might be part of the problem of the tug-of-war, however the cloning needs to do a better job of dealing with existing files at the basis.

Unfortunately this probably won't get a proper fix given the EoL of D7, but these comments might help if node_clone gets ported to Backdrop or YAD7 or another startup flavor after the EoL in 2025.

The patch unfortunately doesn't seem to work in this situation.

I'll note, the Import URL accepts more than 128, but the "fall back" mechanism from the HTTP Fetcher does not.

philsward → created an issue.

philsward → created an issue.

@-Mania-

You're a life saver!

Uninstalling "Update Manager" fixed my problem. None of the other suggestions worked.

I also realized later in testing that the update settings page was throwing errors. If you aren't seeing updates and the settings page is throwing errors, try re-installing the update manager. I could be wrong but I believe it has to do with the email address and how it was stored in past versions.

This is by far one of the dumbest design decisions for Drupal.

Drupal, post 7, is 3 steps backwards on everything except speed and UI. UX...? Not so much.

philsward → created an issue.

Anybody else who's had problems, have antibot installed?

I updated antibot which caused problems logging into the site. I had to uninstall it (thanks D8+ for taking away disable) and re-install it.

This cleared up my antibot issue but also cleared up the problem with admin_toolbar. For me, the only place it had an issue was on the home page. Everywhere else seemed to work fine.

Disabling js aggregation would fix it for me as well before I reinstalled antibot.

Ah. I didn't think to mention to use dev.

Not sure if there is any interest to implement it for that version too.

It would be EXTREMELY helpful for D7.

With Backdrop as the default "replacement" for D7 moving forward, it would be integrated there as well.

Patch #2 applied cleanly and removed the errors.

Unless it needs more testing, it might be ready for RTBC

Only question... Is this change backwards compatible? I don't know enough about PHP to know which version(s) will accept this change. From that thought, it might need some more work.

@c_archer "The SKU has been removed". What do you mean? Does it blank out the SKU on import? Are you using characters such as - or . within the SKU? (If so, it may be an issue with feeds where feeds tamper is needed)

philsward → created an issue.

I had a similar issue as described.

Oddly, I deleted all of the contextual filters and re-created them again. Then it "magically" worked. I had this problem on two different view pages within the same view. It makes me wonder if something didn't save properly which corrupts the DB and deleting then re-creating the contextual filters saves it proper.

I could be grasping at straws in a complete coincidence too...

I can also confirm this bug.

Draggable Views is being overridden by Exposed Filters on the display view (not the sort view)

+1 for an updated release to fix this issue.

RE: @tanay_lakhani

Not sure but I'm guessing it has a requirement for the "content" module which is part of core (I think). I'm guessing this is left over code from D6.

+1

I found that it does add it to cart correctly, but it doesn't show up until the /cart page is refreshed. I don't think it's a caching issue (maybe it is?) but it acts like it's being added after the initial page load and reloading the page makes it show up.

@deja711
> Regarding your 1 in 4 issues. Please check that order complete page is being generated/captured, that was my issue with paypal.
> You should not settle for 1 in 4 detections, as it might be something simple.

As far as I know it is? I'm not a programmer so digging into that is difficult for me. Agreed that 1 in 4 isn't good :(

> Thank you for sharing about Stripe, I will have to check it out.

I'll try to remember to add it to my github so you can download it. I'll let you know.

> Regarding GA4, I will keep you in the loop as we make progress. We are adding add-to-cart, remove-cart, initiate-checkout, and product-details-view to GA4 events. If you look right now you will see that GA4 is not getting that data. That is because the previous UA/GA3 did not send that data either. We just figured out we can put it all in uc_googleanalytics and use hooks for each of those events.

Super excited!

> The latest shimmed GA4 version (latest patch) gave me problems. I am not sure if is fully ready, not sure if it worked for you or gave you issues.

This may be part of my problem... I'm using the latest with the shim and it might be possible that the shim is causing problems.

@deja711 anything you can do will be awesome. This area hasn't seen any love in ages.

I did check again and the reporting is still the same, about 1 in 4.

It's possible it's related to the payment module(s) which is Stripe Checkout (custom coded module) and the stock UC Paypal module.

If you have any interest in Stripe, I can share what I have. It uses their checkout API which puts ALL of the CC data onto their pages/servers so my sites touch zero of that info. I used to use Authorize but they just weren't staying up with the times. We started getting a lot of fraudulent activity and authorize wasn't picking up on it. Stripe seems to be a lot better about that. I have my gripes but overall, it was a good move.

So far I'm getting results, however I still have the problem of UC only sending 1 out of every 4 orders to analytics.

It's better than nothing, but pretty much worthless info at the end of the day.

Thanks @ deja711

Just patched and will wait for data. I'll report back when I get some data or feedback.

@AdamPS

The code was changed in #3052727: Create clear consolidated functions to send/cancel newsletters. I don't really agree it "worked fine" in v2. The purpose of the "Stop sending" button is to stop sending any more emails. Most commonly it would be used before any were sent; it could also be used to abort part way, but then it's not really possible to continue sending as there is no record of who to resend to. Once the newsletter has been sent, it's no longer possible to stop sending, hence the button is should longer be shown. You were using "Stop sending" to reset the newsletter so you could send it again. It is random chance that it worked in that way - it was not logical nor was it the intention.

This does make more sense. For now I'll just use the work-around until it gets stripped completely, then take a look at the resend module you suggested.

I guess make a note that there is "some" demand for the need to resend an existing issue so building it into simplenews might be warranted.

I'm confused though... This worked fine on v2 but it's being stripped from v3?

So all that is needed to fix ✨ Allow resending of newsletters Fixed is to add SIMPLENEWS_STATUS_SEND_READY in the area mentioned above?

ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after end of data: 550-5.7.26 Unauthenticated email from xyzdomain.example is not accepted due to\n550-5.7.26 domain's DMARC policy. Please contact the administrator of\n550-5.7.26 xyzdomain.example domain if this was a legitimate mail. Please\n550-5.7.26 visit\n550-5.7.26 https://support.google.com/mail/answer/2451690 to learn about the\n550 5.7.26 DMARC initiative. n197-20020a25d6ce000000b00b673b42fbecsi13274724ybg.705 - gsmtp

From what I can gather, Drupal isn't setting the correct "from" address and due to DMARC my server is blocking it.

So yes, the email not sending is on my end. However, checking past attempts with SimpleNews to stop and start the message, it did not actually attempt to send the message until after I added the SIMPLENEWS_STATUS_SEND_READY bits.

Hope this is confirmable and not a random freak coincidence.

Update:

I'm not a coder, but sometimes I can find a piece to a puzzle.

This was changed in the patch:

@@ -267,7 +267,7 @@ class SpoolStorage implements SpoolStorageInterface {
    * {@inheritdoc}
    */
   public function deleteIssue(ContentEntityInterface $issue) {
-    if ($issue->simplenews_issue->status != SIMPLENEWS_STATUS_SEND_PENDING) {
+    if (!in_array($issue->simplenews_issue->status, [SIMPLENEWS_STATUS_SEND_PENDING, SIMPLENEWS_STATUS_SEND_PUBLISH])) {
       return;
     }

I added the status to the + line:

SIMPLENEWS_STATUS_SEND_READY,

Which makes:

    if (!in_array($issue->simplenews_issue->status, [SIMPLENEWS_STATUS_SEND_READY, SIMPLENEWS_STATUS_SEND_PENDING, SIMPLENEWS_STATUS_SEND_PUBLISH])) {

Whether it's right or not, I don't know, however stopping the send "appears" to work.

I can't get the emails to actually fire off yet which may be another issue altogether, but at least adding the SEND_READY to that line makes the stopping appear to do what it's supposed to.

Even with the patch, I am unable to use the "Stop Sending" functionality.

@AdamPS I'm sure the module works great in your environment, but I'm saying it doesn't work in mine.

For my workflow, I don't create a new newsletter for every issue, I re-use the same newsletter. All of the info in the newsletter is dynamically created through a View on a daily basis based on the content of the site so there's no reason for me to have to create a new newsletter and send it off like a "normal" workflow might dictate.

In the past, I simply stopped sending, then did a Send Newsletter which would trigger the same newsletter to send again. This unfortunately isn't working now.

Like I stated before, v2 would show a clock while sending. Successfully finished would show the checkmark. I think stop sending would remove the icons completely? v3 on the other-hand shows the checkmark for successfully sending all of the newsletters but stop sending does not remove this checkmark making it act like it never stops sending. Attempting a re-send doesn't ever send anything making it feel like stop sending isn't actually working. Visually, it certainly doesn't "look" like it stops sending.

Updates cleanly against v1.21 on PHP 7.4

How do we run the tests?

Forgot to mention, someone will have to come up with a patch. I have no clue how.

philsward → created an issue.

Any idea if the "cache local" problem was sorted out in the commit or does that still need a separate issue?

@AdamPS I don't know what to tell you for steps. It's pretty straight forward. Stop sending a news letter so you can re-send it and it acts like it doesn't stop because re-sending never works.

The "Send Status" icon never changes from the green checkmark when stopping.

Like nofue mentioned, selecting the news letter, choosing Stop sending and apply to selected items does refresh the page, however it never changes the "Send Status" icon. Thus, turning around and re-selecting the same newsletter and choosing "Send newsletter issue" acts like it works, but no newsletters are actually sent.

For me, simplenews 3.x-dev is completely worthless in my environment. It was upgraded from the 2.x-dev branch which worked just fine.

Environment is PHP 8.0.28

@richard.walker.ardc I ditched Google ReCaptcha in favor of an antibot and honeypot combination. I got a stupid amount of spam using Google's ReCaptcha. ReCaptcha really isn't that good of a service and I suspect they offer it purely for data mining. (Darn those conspiracy theories!)

I know it's overkill to use both, but I get zero bot spam and I've been running this combination for years.

https://www.drupal.org/project/antibot →
https://www.drupal.org/project/honeypot →

Thinking I've run into the same issue. Stopping doesn't seem to work as expected?