eval() should not be a standard feature.

I came to this issue queue to ask about inline twig, that would be just as useful and most of us know how to write that already. I agree on removing php, but that would have to be in a new major release (for BC reasons).

Twig is a usecase that I would love to see implemented however, it's a simple to write, for frontend-types and backend-types (PHP isn't) and it has all the flexibility of PHP without being as insecure.

Totally agreed. This is at least 'normal', if not higher. PHP eval in modules via the UI is extremely scary.

For anyone else that's afraid of leaving this code in your production environments, here's a patch that rips out the PHP evaluation functionality entirely.

I suspect the maintainers won't go for this without adding a twig replacement (or something). But, it's a start for anyone else who wants to make their sites more secure and doesn't use this feature.

Enjoy,
-Derek

Inline Twig would be amaaaaaazing. I love having that ability in (for instance) views rewriting.

But add my +1 for removing this security risk from the module. That said, it seems like it might require a new branch, or at least a big warning that if/when this gets released it might break people's sites.

I'm going to RTBC this and I think Twig can be a follow up if needed.

Reroll, patch attached.

We actually consider this a security issue.

While I support the removal of the PHP evaluation option, there needs to be a good replacement. The ability to write custom PHP is really useful but it should go in a custom module, not in config. However, removing a feature without offering an alternative will force users to stop updating the module, even when a security update is released in the future. To me, that seems like a bigger security issue than the current use of eval(). That's why I don't agree with the RTBC status.

I guess the D8 plugin architecture would be a good fit for a replacement feature: Define a plugin which requires the implementation of a single "generate" method. This method would receive $entity and $language as arguments and return a string. Available plugins can be selected in the UI.

Or... would you say that this is a too advanced feature, and developers who can write PHP shouldn't need the module at all?

I created a new branch because of this issue. Seems to be the best way forward.

Thanks!

For better ways of doing this, please open new issues (unless they exist already).

Thank you Colan, and thumbs up for (co)maintaining this module!

I created an issue to bring back the possibility to define custom label-generation logic: #3070266: Custom label logic with Twig or plugins (as replacement for 'Use PHP').