# Core-2.19 templating changes - preview and testing **URL:** \ **Category:** Project Discussions\ **Tags:** aap, fedora, templating, awx, ansible-lint, ansible-core\ **Created:** [March 3, 2025, 9:43pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759 "2025-03-03T21:43:27Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![nitzmahone](https://avatars.discourse-cdn.com/v4/letter/n/c5a1d2/32.png) [@nitzmahone](https://forum.ansible.com/u/nitzmahone)\ **Post date:** [March 3, 2025, 9:43pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/1 "2025-03-03T21:43:27Z")
## Background Ansible Core 2.19 is slated to receive the [Data Tagging feature](https://github.com/ansible/ansible/pull/84621) we’ve been talking about and developing for several years. It’s been a long process, culminating in the largest set of changes to ansible-core since collections, including a significant overhaul of the templating engine and many other changes we’re hoping you’ll love. We’ve spent a lot of time validating countless backward compatibility scenarios, but a few of the security and templating changes may require adjustments to playbooks. We’ve reached a point where we’re looking for community feedback and testing against pre-releases of ansible-core 2.19. ## How You Can Help Right now, we’re hoping to get feedback around how well existing playbooks and content work with these new features. We’re still working on some plugin API changes and compatibility corner cases, as well as some new ways to more formally define the boundaries of those APIs. The feature PR has merged and is available on ansible-core \>= 2.19.0b1, with continued stabilization leading up to the 2.19 release of ansible-core. ## Getting Help Draft documentation for the new features can be found in the [2.19 porting guide](https://docs.ansible.com/ansible-core/devel/porting_guides/porting_guide_core_2.19.html), including detailed descriptions of the changes and example situations where content changes may be required. ## Reporting Issues Issues specific to these changes should be filed with the [Pre-release Bug Report form](https://github.com/ansible/ansible/issues/new?template=pre_release.yml). ## Getting Started There are two ways to test data tagging currently. ### Installing Using Pip Install a current ansible-core pre-release from PyPI: ```shell $ pip install --upgrade --pre 'ansible-core~=2.19.0b1' ... $ ansible --version ansible [core 2.19.0b1] ... ``` If the installation was successful, the version output should reflect a pre-release build of 2.19. ### Building Execution Environments AAP/AWX Execution Environments can also be created with 2.19 pre-releases via ansible-builder 3.0+ using this method; use `ansible-core~=2.19.0b1` for the ansible\_core → package\_pip entry in the definition file and ensure that the Python interpreter is at least Python 3.1. For example: ```yaml version: 3 images: base_image: name: registry.fedoraproject.org/fedora:41 dependencies: ansible_core: package_pip: ansible-core~=2.19.0b1 ansible_runner: package_pip: ansible-runner python_interpreter: package_system: python3 ``` ---
**Author:** ![ssbarnea](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/ssbarnea/32/4923_2.png) [@ssbarnea](https://forum.ansible.com/u/ssbarnea)\ **Post date:** [March 11, 2025, 10:11am UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/2 "2025-03-11T10:11:55Z")
I would like to know if installing ansible-core devel branch directly from git would also make use of the data tagging feature? I am asking this because most DevTools projects do already have a testing pipeline job that uses ‘devel’ branch of ansible-core. ---
**Author:** ![nitzmahone](https://avatars.discourse-cdn.com/v4/letter/n/c5a1d2/32.png) [@nitzmahone](https://forum.ansible.com/u/nitzmahone)\ **Post date:** [March 11, 2025, 4:32pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/3 "2025-03-11T16:32:22Z")
Once the PR linked above is merged to devel, yes. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [March 11, 2025, 4:57pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/4 "2025-03-11T16:57:40Z")
Right now specifying `refs/pull/84621/head` instead of `devel` for the `ansible-core` branch to use works fine in most CI scripts I’ve seen. (“Works fine” in the sense of that it then runs against the Data Tagging PR. Not in the sense of that everything is just passing 😉 ) ---
**Author:** ![gundalow](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gundalow/32/99_2.png) [@gundalow](https://forum.ansible.com/u/gundalow)\ **Post date:** [March 11, 2025, 7:12pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/5 "2025-03-11T19:12:57Z")
We’ve got a separate discussion around using the new functionality offered by Data Tagging > [@Data tagging playground](https://forum.ansible.com/t/data-tagging-playground/39909): > > In case you heard about data tagging in the past and are wondering when we’ll finally have it, there are some news regarding that: There is now a public PR in ansible/ansible with the current WIP implementation: [[WIP] Templating overhaul, implement Data Tagging by nitzmahone · Pull Request #84621 · ansible/ansible · GitHub](https://github.com/ansible/ansible/pull/84621) This is highly experimental and far from done (as far as I understand), and will take some time to get completed. It’s also a very massive change, and there are still quite a… ---
**Author:** ![gundalow](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gundalow/32/99_2.png) [@gundalow](https://forum.ansible.com/u/gundalow)\ **Post date:** [March 11, 2025, 7:27pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/6 "2025-03-11T19:27:39Z")
Here’s a list of changes we’ve had to make to collections so far: - [Make ready for data tagging by felixfontein · Pull Request #9833 · ansible-collections/community.general · GitHub](https://github.com/ansible-collections/community.general/pull/9833) (open) - [CI: fix string templating for ansible devel (core 2.19, 12 beta) in tests by laurent-indermuehle · Pull Request #713 · ansible-collections/community.mysql · GitHub](https://github.com/ansible-collections/community.mysql/pull/713) - [CI: update matrix by Andersson007 · Pull Request #838 · ansible-collections/community.postgresql · GitHub](https://github.com/ansible-collections/community.postgresql/pull/838) - [Test fixes after DT merge - ci\_complete. by jborean93 · Pull Request #623 · ansible-collections/community.windows · GitHub](https://github.com/ansible-collections/community.windows/pull/623) - [Test fixes after DT merge - ci\_complete by jborean93 · Pull Request #190 · ansible-collections/microsoft.ad · GitHub](https://github.com/ansible-collections/microsoft.ad/pull/190) - [Possible problem with ansible-core 2.19? · Issue #165 · ansible-collections/cloud.common · GitHub](https://github.com/ansible-collections/cloud.common/issues/165) - [Make ready for data tagging by felixfontein · Pull Request #143 · ansible-collections/community.internal\_test\_tools · GitHub](https://github.com/ansible-collections/community.internal_test_tools/pull/143) - [Make ready for data tagging by felixfontein · Pull Request #24 · ansible-collections/community.library\_inventory\_filtering · GitHub](https://github.com/ansible-collections/community.library_inventory_filtering/pull/24) [Improve tests by felixfontein · Pull Request #348 · ansible-collections/community.routeros · GitHub](https://github.com/ansible-collections/community.routeros/pull/348) - [Make ready for data tagging by felixfontein · Pull Request #225 · ansible-collections/community.sops · GitHub](https://github.com/ansible-collections/community.sops/pull/225) - [Make ready for data tagging by felixfontein · Pull Request #149 · ansible-collections/community.hrobot · GitHub](https://github.com/ansible-collections/community.hrobot/pull/149) - [Improve tests by felixfontein · Pull Request #852 · ansible-collections/community.crypto · GitHub](https://github.com/ansible-collections/community.crypto/pull/852) - [Work around bug in ansible-core that censors mailto URIs by felixfontein · Pull Request #859 · ansible-collections/community.crypto · GitHub](https://github.com/ansible-collections/community.crypto/pull/859) - [Fix/improve tests by felixfontein · Pull Request #1052 · ansible-collections/community.docker · GitHub](https://github.com/ansible-collections/community.docker/pull/1052) - [Fix filter tests by felixfontein · Pull Request #247 · ansible-collections/community.dns · GitHub](https://github.com/ansible-collections/community.dns/pull/247) - [Test fixes after DT merge - ci\_complete by jborean93 · Pull Request #772 · ansible-collections/ansible.windows · GitHub](https://github.com/ansible-collections/ansible.windows/pull/772) - [test: fix type casting for ansible-core 2.19 (devel) by jooola · Pull Request #630 · ansible-collections/hetzner.hcloud · GitHub](https://github.com/ansible-collections/hetzner.hcloud/pull/630) - [Fixes issue related to latest ansible-core devel branch by saito-hideki · Pull Request #631 · ansible-collections/ansible.posix · GitHub](https://github.com/ansible-collections/ansible.posix/pull/631) - [add ansible 2.19 support by mikemorency · Pull Request #167 · ansible-collections/cloud.common · GitHub](https://github.com/ansible-collections/cloud.common/pull/167) - [crypttab: removes jijna delimiters from example using when by Akasurde · Pull Request #10079 · ansible-collections/community.general · GitHub](https://github.com/ansible-collections/community.general/pull/10079) - [Fix examples. · ansible-collections/community.dns@e0a7f93 · GitHub](https://github.com/ansible-collections/community.dns/commit/e0a7f9358bd97618e7f5deb86c3c91ca5bbf3467) - [Add ansible-core 2.19 to plugins-integration test target by masa-orca · Pull Request #1515 · ansible-collections/community.zabbix · GitHub](https://github.com/ansible-collections/community.zabbix/pull/1515) - [test: refactor for ansible-core 2.19 by Nemental · Pull Request #419 · ansible-collections/community.grafana · GitHub](https://github.com/ansible-collections/community.grafana/pull/419) - [chore: add ansible 2.19 to test matrices, remove 2.16 by lowlydba · Pull Request #314 · lowlydba/lowlydba.sqlserver · GitHub](https://github.com/lowlydba/lowlydba.sqlserver/pull/314) - [Fixes issue related to latest ansible-core devel branch by saito-hideki · Pull Request #631 · ansible-collections/ansible.posix · GitHub](https://github.com/ansible-collections/ansible.posix/pull/631) - If people DM me links to other PRs I’ll update this list ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [March 11, 2025, 7:45pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/7 "2025-03-11T19:45:30Z")
The above community.general PR is only part of the story; I moved a lot of changes from there out to separate PRs that could already be merged (fixing things that aren’t DT specific that were found by DT, or in some cases working around issues with DT that also work fine with existing releases). This information can also be found by looking at the rebases and the PRs linked, but here’s a complete list: - [Unit tests: make set\_module\_args() a context manager, and remove copies of it in some tests by felixfontein · Pull Request #9838 · ansible-collections/community.general · GitHub](https://github.com/ansible-collections/community.general/pull/9838) - [Simplify module\_utils unit tests by felixfontein · Pull Request #9842 · ansible-collections/community.general · GitHub](https://github.com/ansible-collections/community.general/pull/9842) - [Improve/fix unit tests by felixfontein · Pull Request #9850 · ansible-collections/community.general · GitHub](https://github.com/ansible-collections/community.general/pull/9850) - [cmd\_runner tests: fix reliance on unspecified behavior by felixfontein · Pull Request #9853 · ansible-collections/community.general · GitHub](https://github.com/ansible-collections/community.general/pull/9853) - [Fix/improve tests by felixfontein · Pull Request #9859 · ansible-collections/community.general · GitHub](https://github.com/ansible-collections/community.general/pull/9859) (community.general was the biggest chunk of work, but I had to modify every single collection I maintain. It also resulted in a stream of issues in ansible-core 😉 ) ---
**Author:** ![nitzmahone](https://avatars.discourse-cdn.com/v4/letter/n/c5a1d2/32.png) [@nitzmahone](https://forum.ansible.com/u/nitzmahone)\ **Post date:** [March 13, 2025, 5:12pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/8 "2025-03-13T17:12:00Z")
> [@felixfontein](#): > > It also resulted in a stream of issues in ansible-core 😉 Yep, some of which have already resulted in tweaks to eliminate or minimize those changes… Thanks again for all the early testing and engagement! It’s much easier for us to make those kinds of improvements _before_ the code ships than once it’s been released for a long time. ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [March 17, 2025, 6:21pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/9 "2025-03-17T18:21:46Z")
> [@felixfontein](#): > > Right now specifying `refs/pull/84621/head` instead of `devel` for the `ansible-core` branch to use works fine in most CI scripts I’ve seen. I’m trying out if this also works for Zuul jobs. At least [for community.vmware](https://github.com/ansible/ansible-zuul-jobs/pull/1900). And I think it does. Maybe someone else who knows more about how Zuul works than I do could have another look at this. But I see `Collecting jinja2>=3.0.0 (from ansible-core==2.19.0.dev0)` in the [[DNM] Test data tagging](https://github.com/ansible-collections/community.vmware/pull/2352) logs for the integration tests, whereas it says `Collecting jinja2>=3.0.0 (from ansible-core==2.18.3.post0)` in a [PR without this change to Zuul](https://github.com/ansible-collections/community.vmware/pull/2351). So I guess the integration tests have been really run with data tagging in place. However, I’d like to repeat that I’m not 100% sure. This is just an educated guess. _edit:_ I’ve just added `refs/pull/84621/head` to the sanity and unit tests. This fails, but I’m not sure yet if this has something to do with data tagging or if I run into another problem with 2.19. ---
**Author:** ![gundalow](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gundalow/32/99_2.png) [@gundalow](https://forum.ansible.com/u/gundalow)\ **Post date:** [March 17, 2025, 6:47pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/10 "2025-03-17T18:47:37Z")
Regarding Zuul CI, there is also > > > This PR ensures that integration tests for CI run against both the fallible vers…ion and the devel version of ansible. This helps validate that test changes work across both versions. > > This can be used by adding the following to the collection PR > > Depends-On: ansible/ansible-zuul-jobs#1897 > TestedTargets=target\_1,target\_2,... ---
**Author:** ![rfc2549](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/rfc2549/32/197_2.png) [@rfc2549](https://forum.ansible.com/u/rfc2549)\ **Post date:** [March 23, 2025, 10:50pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/11 "2025-03-23T22:50:01Z")
Hi, I have been a bit busy and out of the loop but did want to take a look at what this meant from the perspective of ara, to see if it broke anything or meant new opportunities. My full notes and screenshots so far are [here](https://github.com/ansible-community/ara/issues/588) but I am giving you a condensed update here. Everything seems to work with the current latest fallible (2025.3.11). That’s a relief 🙂 ara’s integration tests are passing just the same and I must say I like the newer exception, deprecation and error messages, both in stdout and from a callback perspective, being in separate fields. Nice. I have tried to measure the performance improvement claim: > Most nested/recursive templating operations are now fully lazy, vastly improving performance in complex scenarios. From a very naive benchmark that does a debug 10000 times on 100 hosts the performance is about the same: ![Screenshot From 2025-03-23 17-46-54](https://us1.discourse-cdn.com/ansible/original/2X/4/40342064e853b0c76b53faa67b7a8f2b7a4069ad.png) I would be willing to believe it does not exercise that code path but I would be curious to try something that does. Do you have an example “nested/recursive templating” somewhere ? I have tried to find if something like that existed in the integration test targets from the PR but it’s a bit hard to navigate. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [March 29, 2025, 1:40pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/12 "2025-03-29T13:40:23Z")
My _guess_ is that it means something like ```auto - hosts: localhost gather_facts: false tasks: - ansible.builtin.debug: msg: "{{ var }}" vars: var: "{{ sub }} {{ sub }} {{ sub2 }} {{ sub2 }} {{ sub3 }} {{ sub3 }} {{ sub4 }} {{ sub4 }}" sub: ">{{ sub2 }} {{ sub2 }} {{ sub3 }} {{ sub3 }}<" sub2: "[{{ sub3 }} {{ sub3 }} {{ sub4 }}]" sub3: "({{ sub4 }} {{ sub4 }})" sub4: "{{ 42 | ansible.builtin.random }}" ``` But I cannot see differences between the output in devel, stable-2.18, and the DT branch. ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [March 31, 2025, 2:33pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/13 "2025-03-31T14:33:07Z")
I meant to reply with this earlier but I guess I forgot. This is a simplified example, and doesn’t really showcase some of the more complex recursive examples, but there is an improvement in speed for both due to the same “lazier” optimization: ```yaml - hosts: localhost gather_facts: false vars: test: slow: '{{ lookup("pipe", "sleep 5") }}' fast: 'fast' tasks: - debug: msg: '{{ test.fast }}' ``` Something like this is more in alignment with the comment, but is unnecessary in reality to showcase the change: ```yaml - hosts: localhost gather_facts: false vars: slow: static: slow _slow: '{{ lookup("pipe", "sleep 5") }}' test: test: '{{ slow.static }}' tasks: - debug: msg: '{{ test.test }}' ``` Historically the way templating worked, largely due to `AnsibleJ2Vars`, was to do templating immediately on full data structures the moment that a template was found. This is what allows nested templates to work in ansible-core that do not work in jinja2 with it’s builtin functionality. This doesn’t “just work” in jinja2: ```python Environment().from_string('{{ foo }}').render(foo='{{ bar }}', bar='baz') ``` You end up with `{{ bar }}`. As a result, any “slow” paths in the dependent data structure were templated early, and potentially repeatedly. The lazier eval in DT is delayed until needed, and only the paths that are needed, instead of full dependent templating. ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [April 8, 2025, 2:53pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/14 "2025-04-08T14:53:53Z")
I’ve run the playbook (with dozens of tasks using modules from several collections, although mainly `community.vmware`) we use to configure our environment today with fallible. **Only one** problem there, with a `when:`. Looks more like a broken conditional on our side (expected because of your changes) than a bug. I’ll have to investigate this further. Anyway, until I open a bug report count this as a “works for me” 🙂 ---
**Author:** ![nitzmahone](https://avatars.discourse-cdn.com/v4/letter/n/c5a1d2/32.png) [@nitzmahone](https://forum.ansible.com/u/nitzmahone)\ **Post date:** [April 14, 2025, 10:10pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/15 "2025-04-14T22:10:21Z")
I’ve somehow lost my ability to update this post to reflect current suggested testing steps against the 2.19.0 beta instead of `fallible` and the shortcut to the pre-release issue template - working on getting that sorted. Meantime: replace `fallible[compat]` with `ansible==2.19.0b1` in the instructions above. ---
**Author:** ![Jonny](https://avatars.discourse-cdn.com/v4/letter/j/47e85d/32.png) [@Jonny](https://forum.ansible.com/u/Jonny)\ **Post date:** [April 16, 2025, 6:49am UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/16 "2025-04-16T06:49:46Z")
Hello, maybe its the wrong place for it, but what is data tagging can you please explain it to me? I searched for it but found nothing to it. Thanks ---
**Author:** ![oranod](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/oranod/32/1434_2.png) [@oranod](https://forum.ansible.com/u/oranod)\ **Post date:** [April 16, 2025, 9:13am UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/17 "2025-04-16T09:13:39Z")
@Jonny You can find info about data tagging in the PR description at: [Templating overhaul, implement Data Tagging by nitzmahone · Pull Request #84621 · ansible/ansible · GitHub](https://github.com/ansible/ansible/pull/84621) The PR preview build for the 2.19 porting guide also explains a lot: [Ansible-core 2.19 Porting Guide — Ansible Core Documentation](https://ansible--2429.org.readthedocs.build/projects/ansible-core/2429/porting_guides/porting_guide_core_2.19.html#introduction) ---
**Author:** ![Jonny](https://avatars.discourse-cdn.com/v4/letter/j/47e85d/32.png) [@Jonny](https://forum.ansible.com/u/Jonny)\ **Post date:** [April 16, 2025, 9:23am UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/18 "2025-04-16T09:23:48Z")
Thank you! I have also found both links… Unfortunately I don’t understand it 🫠 ---
**Author:** ![johan](https://avatars.discourse-cdn.com/v4/letter/j/dec6dc/32.png) [@johan](https://forum.ansible.com/u/johan)\ **Post date:** [April 16, 2025, 11:49am UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/19 "2025-04-16T11:49:18Z")
Hello, I’m a bit like Jonny, personnaly as a simple playbook author but not a module developer, what is the impact for me ? besides, I see the ‘deprecated’ tag example, but we have seen for a long time these kind of warnings (but about deprecated modules parameters for example) when running playbooks, so it’s not clear yet what it changes for us 🙂 ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [April 16, 2025, 4:28pm UTC](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759/20 "2025-04-16T16:28:40Z")
Data tagging is mostly revamp of the templating system. For playbook authors the main features would be: - Better error information, details should be much clearer and precise - Stronger data types, templating now does a much better job preserving the data types, less numbers converted to strings. - Conditionals are now more strictly evaluated, previouslly some things passed as true/false when they should have been templating errors. - More secure templating, Ansible switched from ‘trusted by default’ to ‘untrusted by default’, this also allows us to remove a lot of processing/filtering/tagging we did to prevent vulnerabilities. For developers, they get a lot of the above, but DT also signals the start of a new way of writing the internal APIs, clearly signaling what is internal (`_internal` prefixed/subdir) and documenting and making explicit which APIs are available for which plugins. [Next page](https://forum.ansible.com/t/core-2-19-templating-changes-preview-and-testing/40759.md?page=2)