bartelsmedia

On 7/3/2023 at 2:49 PM, dragan said:

I have never used ProDrafts, but the docs mention a drafts manager:

Wow, wasn't aware of this. Sorry for this.

But bernards comment is also valid.

Can you hack into the Processwire language tabs and add a drop-down "Translate from language..."?! This would probably be the most flexible UI option.

It is easy to translate from the default language to other languages but it doesn't seem to be possible to start with a secondary language and translate that into the primary language. Or am I wrong?

0.2.0 is now working fine. Thank you so much. One cosmetic/minor suggestion: Could you move the "translate" link from underneath the content box to above the box? It would dramatically help to minimize scrolling back and forth:

Dreams come true! You should put up a donation link.

This is absurdely awesome good news! We spent the last year in the basement busy with copy & paste from/to DeepL and this could come to an an end now.

Thank you very much for the module. Based on latest EU legislation, cookie consent requests must default to NO.

However, if clicking the X in the top-right of the cookie consent dialog, it seems to default to YES:

But it is even worse: In the cookie consent management, no choice is indicated, leaving visitors clueless, whether cookies are stored (while they actually are).

This really seems to be a bug which can bring users into troube. Could you please update the module, so that no cookies are allowed until the user expressly agreed to it?

DeepL is such a strange company. Arising like Phoenix from the Ashes with a beyond mind-staggering service but sales/marketing appears quite autistic for my taste. Apparently, they seem not to be looking for the small fishes. If I would be them, I would offer an affiliate business, motivating guys like you making a module and participate from each use.

Conspiracy theory: DeepL actually is a Google front. Perhaps for legal reasons. Just wild speculation. Mark my words. You read it here first. ?

I really don't want to nit-pick, but sending the domain of "jon@jondonson.com" would still create a privacy issue.

*sigh* Yes, I know, it is pedantic but GDPR legislation is harsh now.

3 hours ago, usualCommission said:

This API is not available to anyone purchasing access from the U.S.

 

Ah, what a fail. Sorry, wasn't aware of this. Too sad. It would be extremely useful.

1 hour ago, usualCommission said:

I think that using a live service is preferable to relying on PW to continually update an internal database unless there's a special use case. Integrating this feature into the Pro form-based modules would be great.

Such list should be pulled by Processwire. Otherwise, you would need to pass user email addresses to (unknown?!) third party.

GDPR alert! ?

.

http://littlesvr.ca/apng/gif_apng_webp.html

This guy put animated WebP to test with somehow disappointing results. Is the test flawed?

What are your experiences?

Now for some cold hard facts:

Screenshot with Retina resolution (21KB after TinyPNG optimization):

The same but rescaled screenshot to 1x resolution (also 21KB after TinyPNG optimization):

Why would I want to generate smaller variations of a screenshot with half the dimensions but almost the identical file size?

I know, that the results depend on the nature of screenshots. Above comparison would fail if the screenshot would contain horizontal color fades or photo-realistic contents. But for such general screenshots it would be better to only serve the original without variations.

Interesting read, thanks. I still think, it is not necessary to provide different bitmap files in the special case of screenshots.

We do screenshots in Retina resolution. Due to the large amount of white space in screenshots, those compress quite well with PNG.

Example: http://www.keyboard-and-mouse-sharing.com/screenshots.htm

Browsers resize those Retina bitmaps quite well for displays with non-Retina resolution.

It would be more data transfer to serve multiple bitmap file variations rather than using one single file that is resized by the browser.

3 hours ago, wbmnfktr said:

Why don't you modify or create your own CSS for it?

Sure, just kindly meant as a suggestion to add this to the offered presets.

I am not referring to uploading bitmaps in the Processwire backend.

I mean the front end bitmap delivery. In \site\assets\files\... I see many variations created that I actually don't need:

Thanks for the very useful module.

Just one issue: Either cookie banner placement has its issues: If placed on top, it gets in the way with the main nav. If placed in the bottom, it may overlay the important "imprint" link often placed in the sub-footer.

How about a small box in the lower left or right?:

Modern browser can resize bitmaps on the client site quite well.

So, shouldn't the Processwire image resize be disabled to reduce additional http requests (if the user resizes viewport)?

Do I miss something? Should/can it be disabled?

The autocomplete feature of the "link insert" is absurdly useful. However it quickly becomes flooded with similar sounding pages in my setup.

Is there a way to filter/exclude certain branches of the page tree from here?

I tried this setting for the unwanted "/menu/" branch but it still shows up:

In an ideal world, each "insert link" dialog would be customizable. Example: The "insert page"dialog fro a page under "/faq/" would show only URL matches of page tree branch "/tech/", etc.

Does this make sense?

4 hours ago, bernhard said:

Also have a look here: 

 

Yes, this is a very cool module, that is already in place. However, I am sorry to say, that the workflow to copy just a repeater is more complex than a simple "copy & paste". ;-)

Great, will have a look. As you mention, it really should be a core feature. It just doesn't make sense to limit the copy&paste scope to one page.

Is there any chance, that a feature us implemented to copy & paste repeaters not only on the same but different pages?

This would be extremely helpful.

Any feedback would be very much appreciated.

Quote

are blacklists usually fairly small, or might it be an existing published list with thousands of domains/emails?

I would say, rather small (max a few dozens to hundreds for bigger companies). YMMV

Quote

The truth to the matter is that unless there's a court case stating essentially that everything (including specifically email addresses) must be encrypted during storage, this can be interpreted in a multitude of ways.

So true. Anyway, you will be asked by the court why you have not made use of such "reasonable measure" like free & easy-to-apply AES encryption in a court case. And a friendly smile will not save you here.

I am not a lawyer but have witnessed many court cases to see the risk. The topic may be difficult to understand for non German businesses who enjoy less strict privacy rules. On the other hand, it would be really benefit of ProMailer compared to other newsletter systems if it would proactively add data security.

--

Regarding subscriber black list: Here is a court case which states, that you must make sure, that you must not send an email to any email of the entire TLD or risk hefty penalties. http://www.gesetze-bayern.de/Content/Document/Y-300-Z-BECKRS-B-2017-N-102179

So, the black list must enable users to optionally block an entire domain belonging to an individual.

Example:

1. A malicious person subscribes to your newsletter.  Think of a competitor or his buddy.

2. He refuses to ever have subscribed and sends you a cease & desist letter because you "spammed him".

3. You have no sufficient evidence to prove the subscription, you then block the particular email and sign the letter which makes it a binding agreement.

4. The guy uses a different email address under the same domain. He then gets another newsletter from you which violates the agreement.

You have to pay $3000-5000 to him.

The success of Mailchimp & Co. may partly be, because companies just can't stand all the legal traps anymore.

ProMailer could provide a solution to this problem with quite easy measures.

5 hours ago, ryan said:

You can only subscribe if you confirm it with your email address (double opt-in). So the only situation where you can subscribe is if you yourself confirm it from your email. You can test it out from here if you'd like. But if someone breaks into your email, then yes they could subscribe you. If that's a concern, then this is another situation where I would avoid email as a medium for communications. We do store the timestamp of both subscription request and confirmation. No IP addresses or information about the browser client are stored by default, but you can store the information on your own if you'd like to.

Please consider it a preconfigured option. We know cases where users refuse to ackknowledge that they registered and then sued for spam. It really is insane and a big business for the law industry. It would help, if ProMailer can provide as much evidence as possible (while it is totally clear, that there is no bullet proof evidence). 

I feel, that there is quite a culture clash between USA and in particular Germany regarding data privacy.

You may run this through google translate: https://www.e-recht24.de/news/marketing-seo/7980-newsletter-a-co-double-opt-verfahren-in-muss-dokumentiert-werden.html