Add option to inverse result of ArrayHelper::filterByValue

[rungta]

Currently ArrayHelper::filterByValue filters an array by keeping items that match the given value. It would be great to have an option that would reverse this behaviour, i.e. remove items that match the given value and keep the rest.

Here's a use case:

{% set eventInfo = [{
  title: 'Event type',
  body: entry.eventType.all()|join(","),
},{
  title: 'Venue',
  body: entry.venue|nl2br,
},{
  title: 'Cost',
  body: entry.cost|nl2br,
}] %}

I would like to remove all items where body is an empty string.

[brandonkelly]

You can pull this off with filterByValue:

{% set filteredEventInfo = eventInfo|filterByValue('body', '') %}

[rungta]

This gives me an array where the body value of all items in filteredEventInfo are empty strings. I want an inverse of that. E.g.:

{% set eventInfo = [
  { title: 'Event type', body: 'Conference' },
  { title: 'Venue', body: 'Auditorium' },
  { title: 'Cost', body: '' }
] %}
{% set filteredEventInfo = eventInfo|filterByValue('body', '') %}
{{ dump(filteredEventInfo) }}

{# [
  { title: 'Cost', body: '' },
] #}

Whereas what I’m after is this:

{# Fictional removeByValue filter #}
{% set inverseEventInfo = eventInfo|removeByValue('body', '') %}
{{ dump(inverseEventInfo) }}

{# [
  { title: 'Event type', body: 'Conference' },
  { title: 'Venue', body: 'Auditorium' },
] #}

[brandonkelly]

Ah sorry, I missed the word “remove”.

I just updated Twig to 2.11 for the next release, from 2.8. Twig 2.10 introduced a new filter filter, which can be used for what you want:

{% set filteredEventInfo = eventInfo|filter(event => event.body is not empty) %}

[dueddel]

Hi @brandonkelly,

unfortunately the update from 2.8 to 2.11 breaks my site.

In one of my Twig templates I import another template containing a macro that I am calling.

{% import ['path/to/templateWithMacro'] as module %}
{# do some stuff with `module` here like `{% module.render(…) %}` #}

After upgrading Craft from 3.1.28 to the current release (as of writing this: 3.1.29) I get the following error:

Twig Runtime Error – Twig\Error\RuntimeError
Variable "module" does not exist.

I can see that Twig introduced some changes with 2.11 for the macro feature, but I am not aware what this has to do with my code snippet above which is now broken.

Long story short:
Upgrading Twig from 2.8. to 2.11 seems to make the new Craft release actually not just a minor update anymore because it is not 100% backwards-compatible (which it would be if it still worked after upgrading). At least in my case it breaks the site. Could you please check that? I hope I don't tell you some bullshit. ;)

(If you need more insights or whatever, I could also write you on Discord, if you perfer that one…)

Thanks in advance for your help.

[brandonkelly]

@dueddel I’m not able to reproduce that.

I just created two templates:

test.html

{% import ['test2'] as module %}

{{ module.render() }}

test2.html

{% macro render() %}
    <p>Hey</p>
{% endmacro %}

Accessing /test from my browser is outputting <p>Hey</p> as expected, and I’ve tested on Twig 2.11.0, 2.11.1, and 2.11.2.

Twig 2.11.1 and 2.11.2 both mention macro fixes in the changelog, so perhaps you had either 2.11.0 or 2.11.1 installed and the bug has been fixed now. You can see which version of Twig you have installed from Utilities → System Report in the Control Panel. If you are on an older version, you can pull in the latest by running the composer update command in your terminal.

If you’re still seeing the bug on Twig 2.11.2, try to come up with a simplified example that demonstrates the issue, and then report it over at https://github.com/twigphp/Twig/issues.

[dueddel]

Damn. Then it must be something different. It's 2.11.2, I checked that yesterday already. Nevertheless, thank you for testing!

I admit that I only told you half of the truth. The code on our side isn't as simple as in my example and in your templates above. There is going on some dynamic stuff like dynamically loading the template and reading the loaded template's source for checking its contents. (I spare you with details. 😉)
But in the end, even that isn't such of a big deal since it's working like a charm. The Twig update mystically breaks it, though…

I'll dive in deeper a bit. Thanks again!

[dueddel]

I still have no idea why import … as … did not work in our case, but at least I could fix it now by using from … import … as … instead.

Here an example that is more sophisticated somehow. 🤓

{# dynamically load the template #}
{% set template = '…the actual template name is determined using to some magic powder… ;-)' %}
{% from ['path/to/' ~ template, 'path/to/fallbackTemplate'] import render as renderModule, renderMultiple as renderModules %}

{# render the module(s) as defined in the template #}
{% if renderModule is defined %}
    {% renderModule('param list …') %}
{% endif %}
{% if renderModules is defined %}
    {% renderModules('any other parameters …') %}
{% endif %}

It's also a bit closer to our actual code than the snippet from my first comment. 🙃

So, I got it now with said from … import … as …. Thanks again for trying, @brandonkelly.

[brandonkelly]

@dueddel Were you able to come up with a simplified example where it breaks? If so please do report it at https://github.com/twigphp/Twig/issues so they can get the bug fixed.

[dueddel]

Unfortunately not. 😕

In one of my other projects (where similar imports are made) it didn't break. I have no clue what's wrong with import … as … while from … import … as … is working.

Whenever I come up with something more I'll report it.

[samuelbirch]

i've just updated and got the same issue :(

[brandonkelly]

@samuelbirch Same goes for you then. #4342 (comment)