learned from 10 years/millions of users in production

10 years per millions of users is an interesting metric :P

Maybe all bunnies are actually snails with a fur coat on.

What a mess.

URL is still advanced-custom-fields, but then named Secure Custom Fields. Translations and source repo still map to the old name. It definitely is a takeover, not a "fork" in the classic, established sense.

The problem with the takeover is, of course, that the original publisher still develops, publishes, and sells their original plugin. Their official website now serves their own version with their own update source.

So you kinda don't but also have to rename it to avoid confusion.

I think a rename to something different is wrong and confusing though. It should add a disclosing addition, like "(Taken Over)" or "Adjusted" or "WPorg edition".

A supposed, partial rename is confusing. No information in the README is confusing, intransparent, and disingenuous. No clarity in the release notes is confusing.

Simply freeing previously and still sold pro features, without disclosing that fact, is very questionable. Not fair to the developers and certainly not transparent to the community.

Clearing the changelog and release log documentation, removing previously available information, is questionable as well.

I see in the readme.txt file that the plugin is licensed under GPL.

So the changes are permissible. And being able to do so is certainly a strength of the FOSS license.

My biggest issue is that they remove information, and rename without indication. It should be transparent and, within context and concerns, fair. Not like this.

Looking at the commit log:

6 days ago, 6.3.6.1 was tagged with

Security - ACF defined Post Type and Taxonomy metabox callbacks no longer have access to $_POST data. (Thanks to the Automattic Security Team for the disclosure)

14 hours ago, 6.3.6.2 and rename

• Security - Harden fix in 6.3.6.1 to cover $_REQUEST as well.
• Fork - Change name of plugin to Secure Custom Fields.

It also removes is-pro and pro-license-active checks, but fails to disclose so in the release notes.

Effectively, it frees pro functionalities.

It also removes all previous change log and release information.

Using Mitchell's donation we'll be able to to offer Jacob Young a full time schedule. As a reminder, he's the primary author of the C backend, x86 backend, LLDB fork that adds Zig support, and maintains the eZ80 toolchain on the side, all without even having the ability to bill full time yet!

You're good to keep your skepticism. If you trust them, the ones creating the tutorial to have vetted to a degree, or that a very popular package like that is vetted to a reasonable degree, you'll just go ahead with it. (Like most people do without questioning it.)

You'll need considerable experience and insight to do good, reasonable risk assessment. Without that, you can either trust and hope in others, or skip the ecosystem and look for alternative technologies.

It's also worth noting that your potential impact is considerable lower if you're only doing local test and development work, not publishing or publicly serving anything. I'm not personally familiar if or to what degree running arbitrary local commands has been limited in the npm ecosystem by now.

The items don't seem concise and always clear. But seems like a good, inspiring resource for things to consider.

If it is expected that a method might fail, then it should fail, either by throwing an Exception or, if not - it should return a special case None/Null type object of the desired class (following the Null Object Pattern), not null itself.

I've never heard of evading null with a Null object. Seems like a bad idea to me. Maybe it could work in some language, but generally I would say prefer result typing. Introducing a result type wrapping or extending the result value type is complexity I would be very evasive to introduce if the language doesn't already support result wrapper/state types.

I find LINQ query syntax less readable than SQL. I like LINQ method syntax for simple, linear queries.

The linear method syntax is somewhat like the idea of piping SQL operations.

It good

The Roast my profile in question.

Your 105 repos resemble a crowded yard sale, filled with half-baked ideas and a couple of dusty gems.

lol

https://docs.github.com/en/site-policy/privacy-policies/github-general-privacy-statement#private-repositories-github-access

? Nothing about such private repo access listed there.

People regularly change email addresses. Listing that as an example is a particularly bad example in my opinion.

I hope the demo starts soon…

(What a bullshit correlation/equation to start with.)