Jinja: 2.9 regresi saat menetapkan variabel di dalam loop

Dibuat pada 7 Jan 2017  ·  65Komentar  ·  Sumber: pallets/jinja

2.9:

>>> jinja2.Template('{% set a = -1 %}{% for x in range(5) %}[{{ a }}:{% set a = x %}{{ a }}] {% endfor %}{{ a }}').render()
u'[:0] [:1] [:2] [:3] [:4] -1'

2.8:

>>> jinja2.Template('{% set a = -1 %}{% for x in range(5) %}[{{ a }}:{% set a = x %}{{ a }}] {% endfor %}{{ a }}').render()
u'[-1:0] [0:1] [1:2] [2:3] [3:4] -1'

Awalnya dilaporkan di IRC:

Perubahan dalam pelingkupan jinja2 tampaknya memengaruhi saya, dan saya tidak yakin dengan perbaikan yang benar. Secara khusus masalahnya adalah penugasan tahun di sini: https://github.com/kennethlove/alex-gaynor-blog-design/blob/551172/templates/archive.html#L13 -L24

Komentar yang paling membantu

changed_from_last terdengar bagus - setidaknya dari segi fungsionalitas, namanya sendiri agak canggung IMO. Mungkin changed saja sudah cukup jelas?

Saya kira elemen pertama akan selalu dianggap "berubah" tidak peduli apa itu? Jika perilaku itu tidak baik untuk seseorang, mereka selalu dapat menambahkan cek not loop.first .

Semua 65 komentar

Sementara perilaku saat ini salah, perilaku lama pasti salah juga. Tag {% set %} tidak pernah dimaksudkan untuk mengesampingkan cakupan luar. Saya terkejut itu terjadi dalam beberapa kasus. Tidak yakin apa yang harus dilakukan di sini.

Perilaku yang saya anggap benar adalah output seperti [-1:0] [-1:1] [-1:2] [-1:3] [-1:4] -1 .

Dalam kasus khusus ini saya menyelesaikannya dengan menulis ulang untuk menggunakan groupby .

Saya merasa ini adalah kasus penggunaan yang agak umum - juga hal-hal seperti {% set found = true %} dalam satu lingkaran dan kemudian memeriksanya setelahnya. Ini pasti akan merusak barang-barang bagi orang-orang ketika ini berhenti bekerja ...

Saya terkejut ini berhasil sebelumnya. Apakah ini selalu berhasil?

rupanya ya:

>>> import jinja2
>>> jinja2.__version__
'2.0'
>>> jinja2.Template('{% for x in range(5) %}[{{ a }}:{% set a = x %}{{ a }}] {% endfor %}{{ a }}').render()
u'[:0] [0:1] [1:2] [2:3] [3:4] '

Besar. Karena masalahnya di sini adalah bahwa ini sama sekali tidak masuk akal. Variabel mana yang seharusnya ditimpa? Bagaimana jika ada ruang lingkup fungsi di antaranya. misalnya: makro atau sesuatu seperti itu. Saya tidak tahu bagaimana mendukung ini sekarang.

hmm mungkin mirip dengan pelingkupan python dengan asumsi tidak ada nonlocal yang digunakan)? yaitu jangan izinkan mengesampingkan sesuatu yang ditentukan dalam lingkup luar (yaitu jika ada makro peralihan) tetapi izinkan menimpanya selain yang lain?

Rupanya sebelum ini tertangkap dengan kesalahan pernyataan templat:

>>> Template('{% set x = 0 %}{% for y in [1, 2, 3] recursive %}{{ x }}{% set x = y %}{% endfor %}').render()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
jinja2.exceptions.TemplateAssertionError: It's not possible to set and access variables derived from an outer scope! (affects: x (line 1)

perilaku tampaknya berbeda dengan/tanpa rekursif (2.8.1 memberi saya kesalahan UnboundLocalError dengan rekursif dan '012' tanpa)

Kesalahan lokal yang tidak terikat harus diselesaikan pada master.

Saya tidak yakin bagaimana kemajuan di sini. Saya sangat tidak suka bahwa tampaknya mungkin untuk melakukan hal semacam ini.

Dengan perubahan terakhir saya akan menutup ini sebagai "berfungsi sebagaimana dimaksud". Jika ada dampak lebih lanjut dari ini, kami dapat menyelidiki alternatif lagi.

Dikirim ke masalah ini (lihat #656) setelah perubahan ini meledakkan template blog saya saat memutakhirkan dari v.2.8.1 ke v2.9.4.

Saya menggunakannya untuk melacak jika berbagai bagian data berubah di antara iterasi loop. Saya dapat memperbaikinya karena saya menulis kode templat asli (lihat https://github.com/MinchinWeb/seafoam/commit/8eb760816a06e4f0382816f82586204d1e7734fd dan https://github.com/MinchinWeb/seafoam/commit/89d555dbd6a2f256471d43e ragu saya akan bisa sebaliknya. Kode baru lebih sulit untuk diikuti karena perbandingannya sekarang dilakukan secara in-line. Misalnya, kode lama saya (v.2.8.1):

{%- set last_day = None -%}

{% for article in dates %}
    {# ... #}
    <div class="archives-date">
        {%- if last_day != article.date.day %}
            {{ article.date | strftime('%a %-d') }}
        {% else -%}
            &mdash;
        {%- endif -%}
    </div>
    {%- set last_day = article.date.day %}
{% endfor %}

dan kode baru, dengan perbandingan sebaris (v2.9.4):

{% for article in dates %}
    {# ... #}
    <div class="archives-date">
        {%- if ((article.date.day == dates[loop.index0 - 1].date.day) and
                (article.date.month == dates[loop.index0 - 1].date.month) and 
                (article.date.year == dates[loop.index0 - 1].date.year)) %}
                    &mdash;
        {% else -%}
                    {{ article.date | strftime('%a %-d') }}
        {%- endif -%}
    </div>
{% endfor %}

Jadi saya hanya ingin mengatakan bahwa "fitur" (atau "hack", jika Anda suka) digunakan dan sudah terjawab.

Jika masalah pelingkupan terlalu rumit untuk dipahami saat ini, dapatkah sesuatu (minimal) ditambahkan ke changelog sehingga menggigit lebih sedikit orang yang tidak sadar?

Saya tidak menyadari bahwa ini disalahgunakan secara luas :-/ Yang menjengkelkan, sebenarnya tidak ada cara untuk membuat ini bekerja dengan cara yang dapat diandalkan. Namun saya ingin tahu apakah kita dapat mengisolasi kasus penggunaan umum di sini dan memperkenalkan api yang lebih bagus.

Secara khusus mungkin kita ingin menambahkan sesuatu seperti ini ( loop.changed_from_last ):

{% for article in dates %}
    <div class="archives-date">
        {%- if loop.changed_from_last(article.date.day) %}
            {{ article.date | strftime('%a %-d') }}
        {% else -%}
            &mdash;
        {%- endif -%}
    </div>
{% endfor %}

changed_from_last terdengar bagus - setidaknya dari segi fungsionalitas, namanya sendiri agak canggung IMO. Mungkin changed saja sudah cukup jelas?

Saya kira elemen pertama akan selalu dianggap "berubah" tidak peduli apa itu? Jika perilaku itu tidak baik untuk seseorang, mereka selalu dapat menambahkan cek not loop.first .

Mungkin previous_context hanya menampung seluruh konteks sebelumnya, daripada mencoba memutuskan apa yang akan dilakukan pengguna dengannya.

hanya previous atau prev ? "konteks" terdengar agak membingungkan dalam konteks ini (tidak ada permainan kata-kata)

..... dan sekarang saya sudah bisa membayangkan seseorang meminta next :/

Atau mungkin pernyataan eksplisit untuk menulis di luar ruang lingkup: set_outer atau sesuatu.

saya sedang memikirkan ini:

class LoopContextBase(object):

    def __init__(self, recurse=None, depth0=0):
        ...
        self._last_iteration = missing

    def changed(self, *value):
        if self._last_iteration != value:
            self._last_iteration = value
            return True
        return False

@davidism kita tidak bisa melakukan set_outer tanpa merusak seluruh sistem pelingkupan. Ini akan mengacaukan semuanya.

Ya, pikir itu akan terjadi. Saya mengantisipasi "bagaimana jika saya ingin tahu apakah nilai saat ini lebih besar dari sebelumnya", atau yang serupa. Tapi saya suka metode changed juga.

Sebagai titik data tambahan, itu jatuh pada kaki saya untuk kasus di mana saya perlu menyuntikkan kelas khusus ke dalam HTML yang dihasilkan, tetapi hanya untuk elemen pertama dari daftar berulang yang juga tidak memiliki beberapa set properti tertentu. Saya tidak dapat mengubah data yang diulang. Saya tidak dapat menggunakan loop.first (sebanyak yang saya inginkan) atau membandingkan dengan apa pun dari elemen terakhir untuk melakukan apa yang perlu saya lakukan dengan andal di sini, yang mengarah pada eksperimen dengan konstruksi jahat yang bekerja dengan sempurna (dan tidak jelas bagi saya bahwa sebenarnya saya menyalahgunakan bug).

Selain itu saya menawarkan kemampuan ekstensi melalui plugin pihak ketiga dan tidak memiliki cara untuk mengawasi bagaimana penulis menyusun template mereka, menyebabkan kerusakan mendadak bagi pengguna akhir setelah pembaruan ke Jinja 2.9+. Saya telah menyematkan versi 2.8 terbaru sekarang di program saya agar tetap kompatibel (seperti yang dijanjikan skema versi saya), sampai saya dapat menemukan cara untuk membuat penulis memperbarui template mereka.

Bisakah seseorang tolong jelaskan mengapa lingkup jinja2 tidak dapat bekerja persis seperti python bekerja? yaitu, templat jinja2 sesuai dengan modul python, makro sesuai dengan fungsi (dan memiliki ruang lingkupnya sendiri), karena loop tidak memiliki ruang lingkupnya sendiri dan seterusnya. Sementara @mitsuhiko mengatakan jinja 2.8 dan di bawahnya memiliki banyak bug pelingkupan, lebih intuitif bagi saya untuk memahami cara kerja pelingkupan.

Untuk programmer python, perilaku dari posting pertama (Jinja 2.8) sudah jelas. Hal yang sama berlaku untuk https://github.com/pallets/jinja/issues/660 , saya tidak mengerti mengapa perpustakaan python harus mengimplementasikan perilaku javascript (Saya mengerti bahwa penanganan python terhadap args default tidak ideal, tetapi pengembang python mengetahuinya itu).

Atau, harus ada dokumen yang menjelaskan cara kerja pelingkupan dalam jinja sehingga kita tidak perlu menebak-nebak.

Juga tolong jangan ambil komentar saya secara negatif, saya sangat berterima kasih untuk jinja.

@roganov beberapa catatan tentang ini:

Bisakah seseorang tolong jelaskan mengapa lingkup jinja2 tidak dapat bekerja persis seperti python bekerja

Karena pelingkupan Python menurut saya sangat buruk, terutama di templat karena Anda dapat dengan mudah menimpa informasi penting secara tidak sengaja.

Sementara @mitsuhiko mengatakan jinja 2.8 dan di bawahnya memiliki banyak bug pelingkupan, lebih intuitif bagi saya untuk memahami cara kerja pelingkupan.

Perhatikan bahwa ini adalah pengecualian karena bug dan hanya berfungsi dalam beberapa situasi terbatas dan murni karena kecelakaan. Jinja selalu memiliki aturan pelingkupan terdokumentasi yang sama dan perilaku ini tidak pernah didokumentasikan. Setiap saat dikatakan bahwa variabel tidak menyebar ke lingkup luar. Anda dapat dengan mudah melihat ini karena setelah akhir loop, variabel tidak pernah disetel.

Atau, harus ada dokumen yang menjelaskan cara kerja pelingkupan dalam jinja sehingga kita tidak perlu menebak-nebak.

Saya telah meningkatkan dokumen beberapa hari yang lalu untuk ini

Bagaimana jika ada cara untuk secara eksplisit meneruskan variabel ke dalam satu lingkaran? Mungkin sintaksnya seperti ini (meminjam dari filter teks):

{%- set last_day = None -%}

{% for article in dates | pass_variable ( last_day ) %}
    {# ... #}
    <div class="archives-date">
        {%- if last_day != article.date.day -%}
            {{ article.date | strftime('%a %-d') }}
        {%- else %}
            &mdash;
        {% endif -%}
    </div>
    {%- set last_day = article.date.day %}
{% endfor %}

Atau adakah cara untuk melakukan sesuatu yang mirip dengan scoped seperti yang saat ini berlaku untuk makro?


Kasus penggunaan lain akan mempertahankan semacam penghitung di antara loop. Misalnya, berapa banyak baris total? berapa banyak baris yang memenuhi beberapa kriteria? Total beberapa properti untuk baris yang dipilih (untuk mencetak total baris)?

Sintaks filter tidak akan dimungkinkan di sini karena filter sudah dimungkinkan pada iterable.

Sintaks yang mungkin untuk ini yang tidak akan terlihat buruk adalah ini:

{% for article in dates with last_day %}

Terutama karena with sudah melakukan pelingkupan di Jinja saat digunakan misalnya sebagai {% with %} . OTOH, di sini akan menjadi sebaliknya karena dengan blok membuka ruang lingkup baru, tidak membuat vars lingkup luar dapat diakses..

Tidak yakin apakah itu fitur yang dibutuhkan Jinja atau tidak.

Tidak ada sintaks yang akan mengubah ini karena masih akan menumbangkan aturan pelingkupan. Anda tidak dapat melakukannya dengan kompilasi saat ini atau sistem pelacakan id. Bahkan jika itu berhasil untuk kasus sederhana itu, apa yang terjadi jika seseorang memiliki for loop yaitu recursive . Bagaimana jika seseorang mendefinisikan makro dalam for loop. Bagaimana jika blok panggilan muncul di for loop.

Saya pikir akan lebih masuk akal untuk memperkenalkan objek global yang bertindak sebagai ruang nama penyimpanan dan kemudian dapat dimodifikasi dengan . Misalnya:

{% set foo = namespace() %}
{% set foo.iterated = false %}
{% for item in seq %}
  {% set foo.iterated = true %}
{% endfor %}

Namun ini akan membutuhkan tag set untuk berubah secara mendasar.

@mitsuhiko dan pola semacam itu sudah digunakan dengan tag do : http://stackoverflow.com/a/4880398/400617

FWIW, solusi dengan do sangat buruk. Sama seperti solusi yang digunakan orang di Python 2 ketika mereka membutuhkan nonlocal ...

Saya sepenuhnya setuju, hanya menunjukkan bahwa itu ada di luar sana. Dan seperti yang ditunjukkan Alex, banyak dari masalah ini dapat ditulis ulang, baik dengan filter atau dengan meletakkan beberapa logika di Python.

Peretasan (jelek) lainnya adalah menggunakan daftar, tambahkan, dan pop: http://stackoverflow.com/a/32700975/4276230

Hai, saya telah menggunakan kode ini sejak sekitar 2 tahun, sekarang rusak dan dari dokumentasi baru dan diskusi ini saya tidak berpikir ada cara lain untuk melakukan apa yang saya coba lakukan di sini. Jika tidak mohon koreksi saya.

{% set list = "" %}
{% for name in names %}
{% if name.last is defined %}
{% set list = list + name.last + " " %}
{% if loop.last %}
{{ list.split(' ')|unique }}
{% endfor %}

@pujan14

{{ names|map(attribute="last")|select|unique }}

Meskipun unique bukan filter bawaan, Anda selalu dapat menambahkan filter lain yang melakukan semuanya, karena Anda sudah menambahkan filter unique .

Hai,
Saya mengerti bahwa ada banyak contoh "jelek" karena hal ini, tetapi bisakah Anda memberi saran bagaimana cara menambah variabel pada for loop di template jinja dengan cara yang elegan/benar? Karena kode saya telah rusak juga.

Mengapa Anda perlu melakukannya sama sekali? Juga, harap sertakan kode Anda.

{% for state in states.sensor -%}
{% if loop.first %}
{% set devnum = 0 %}
{% endif -%}
{%- if state.state == "online" %}
{% set devnum = devnum + 1 %}
{%- endif -%}
{% if loop.last %}
{{ devnum }}
{% endif -%}
{%- endfor -%}

dapatkah Anda memberi saran bagaimana cara menaikkan variabel pada for loop di template jinja dengan cara yang elegan/benar?

Anda seharusnya tidak pernah melakukan (atau mampu melakukan) ini sama sekali. Jadi jawabannya adalah jangan lakukan itu. Namun kami tertarik mengapa penulis template tampaknya memiliki kebutuhan untuk melakukan itu.

Jinja sudah menghitung loop. {{ loop.index0 }}

@davidism Saya hanya membutuhkan yang memenuhi syarat

Tulis filter yang menghasilkan tupel devnum, sensor persis seperti yang Anda butuhkan. Atau hitung dengan Python dan berikan ke template. Atau gunakan contoh di bawah ini. Ini berlaku untuk setiap contoh lain yang pernah saya lihat.

@Molodax Anda dapat melakukan ini:

{{ states.sensor|selectattr('state', 'equalto', 'online')|sum }}

bukankah maksudmu |count ?

Maaf ya, hitung.

@mitsuhiko , terima kasih atas dukungan Anda, sayangnya, itu tidak berhasil.
Mungkin, jinja2 (filter) telah diimplementasikan dengan beberapa batasan dalam proyek yang menggunakan ( Asisten rumah ). Tapi itu berhasil dengan kode yang saya berikan sebelumnya. Kasihan.

Hai teman-teman. Anda meminta contoh kode yang berfungsi di bawah 2.8, jadi ini milik saya:

{% set count = 0 %}
{% if 'anchors' in group_names %}
nameserver 127.0.0.1
{% set count = count+1 %}
{% endif %}
{% for resolver in resolvers %}
{% if count < 3 %}
{% if resolver|ipv6 and ansible_default_ipv6.address is defined %}
nameserver {{ resolver }}
{% set count = count+1 %}
{% elif resolver|ipv4 and ansible_default_ipv4.address is defined %}
nameserver {{ resolver }}
{% set count = count+1 %}
{% endif %}
{% endif %}
{% endfor %}

Saya tidak tahu bagaimana saya akan melakukan ini tanpa variabel "hitungan" global yang dapat saya rujuk dalam 2 loop terpisah. Apakah Anda memiliki saran yang memungkinkan ini bekerja di bawah 2.8 dan 2.9?

@davidism Solusi Anda bagus tapi saya mencoba untuk mencapai ini.
Buat 2 daftar sebagai berikut

{% set list1 = name|default()|map(attribute="last")|select|list %}
{% set list2 = name|default()|map(attribute="age")|select|list %}

dan kemudian gabungkan mereka ke dalam list3, yang akan terlihat seperti berikut dan akhirnya menerapkan unik (filter yang memungkinkan) pada list3
terakhir1-usia1
terakhir2-usia2
terakhir3-usia3
4-usia terakhir4
5-usia terakhir5
6-usia 6 tahun terakhir

Dari apa yang saya kumpulkan, peta tidak berfungsi dengan banyak atribut #554
Saya menggunakan jinja2 melalui ansible dan menambahkan melakukan sesuatu dengan python sebelumnya bukanlah ide yang baik untuk saya.

@pujan14 @aabdnn @Molodax apakah pola ini berasal dari dokumentasi resmi Ansible, atau apakah itu sesuatu yang Anda buat atau temukan di tempat lain? Either way, mungkin lebih mudah untuk melaporkan ini ke Ansible, karena mereka memahami bagaimana produk mereka harus digunakan dan mungkin bisa memberikan solusi yang lebih relevan.

@davidism template yang saya sajikan di atas tidak berasal dari dokumentasi Ansible. Ansible tidak mendokumentasikan Jinja2 secara khusus. Saya baru saja membuat template ini sendiri dengan membaca dokumentasi Jinja2, dan berhasil, jadi saya memasukkannya ke dalam produksi. Saya berasumsi bahwa Jinja2 membuat variabel menjadi global.

Jika tidak didokumentasikan secara resmi maka saya lebih cenderung menutup ini seperti aslinya. Saya akan menegaskan kembali bahwa Ansible mungkin dapat membantu Anda lebih banyak dalam hal ini.

@davidism Saya bermain-main dengan loop di jinja 2.9 baru .
Berikut adalah contoh.

{% for name in names %}
{% if loop.first %}
{% set list = "" %}
{% endif %}
{% if name.first is defined and name.last is defined and not name.disabled %}
{% set list = list + name.first|string + "-" + name.last|string %}
{% if loop.last %}
{% for item in list.split(' ')|unique %}
{{ item }}
{% endfor %}
{% else %}
{% set list = list + " " %}{% endif %}
{% endif %}
{% endfor %}

Ini mungkin bukan cara terbaik untuk melakukan ini, tetapi di sini dari pemahaman saya, saya tidak melanggar aturan pelingkupan.

Punya masalah ini di 2.8 dan lebih tinggi

Ini dia kasus uji:

import unittest
from jinja2 import Template

TEMPLATE1 = """{% set a = 1 %}{% for i in items %}{{a}},{% set a = a + 1 %}{% endfor %}"""

class TestTemplate(unittest.TestCase):

  def test_increment(self):
    items = xrange(1,10)
    expected='%s,' % ','.join([str(i) for i in items])
    t = Template(TEMPLATE1)
    result = t.render(items=items)
    self.assertEqual(expected,result)

unittest.main()

Gunakan loop.index sebagai gantinya.

Saya pikir menyediakan akses ke nilai loop sebelumnya melalui atribut objek loop adalah satu-satunya solusi yang baik untuk ini. Saya baru saja menemukan cuplikan ini di proyek kami yang tidak dapat diselesaikan dengan hanya memeriksa apakah objek terakhir berbeda dari yang sekarang dan groupby juga tidak berfungsi di sana karena ini lebih dari sekadar akses item/atribut sepele untuk mendapatkan kunci :

{% set previous_date = none %}
{% for item in entries -%}
    {% set date = item.start_dt.astimezone(tz_object).date() %}
    {% if previous_date and previous_date != date -%}
        ...
    {% endif %}
    {% set previous_date = date %}
{%- endfor %}

Ya itu terdengar seperti sebuah ide.

Bagaimana dengan menambahkan metode set(key, value) dan get(key) ke objek loop? Kemudian orang dapat menyimpan apa pun yang mereka inginkan di loop.

Punya ide yang sama, tetapi kemudian tidak dapat menemukan kasus yang tidak jelek di mana ini diperlukan. Dan saya sudah bisa melihat seseorang meminta setdefault , pop dan metode seperti dict lainnya.

@davidism @ThiefMaster saya berpikir untuk hanya memiliki objek penyimpanan yang tersedia. Seperti ini:

{% set ns = namespace() %}
{% set ns.value = 42 %}
...{% set ns.value = 23 %}

Jelas set tidak dapat mengatur atribut saat ini tetapi ini dapat dengan mudah diperpanjang. Karena tidak ada penugasan kembali ke namespace itu sendiri yang terjadi, ini cukup aman untuk diterapkan.

Tampaknya baik-baik saja bagi saya, ini adalah solusi yang sama dengan nonlocal untuk Py 2. Atau, secara otomatis mengatur loop.ns , meskipun itu tidak akan tersedia di luar loop.

Apa yang saya tidak suka dengan namespace adalah bahwa itu akan terasa sangat menggoda untuk melakukan {% set obj.attr = 42 %} dengan obj menjadi sesuatu yang bukan namespace() - sesuatu yang menurut saya seharusnya tidak berfungsi .

Kalau tidak, sepertinya ide yang menarik, meskipun saya pikir previtem / nextitem / changed() menutupi kasus "sederhana" dengan baik tanpa "kebisingan" karena harus mendefinisikan objek baru dalam templat.

@ThiefMaster itu tidak akan berhasil. Cara saya melihat ini berfungsi adalah bahwa penetapan atribut melalui panggilan balik pada lingkungan yang hanya akan mengizinkan modifikasi pada objek namespace.

ok, jadi setidaknya tidak ada risiko templat yang menyebabkan efek samping tak terduga pada objek yang diteruskan ke mereka.

masih sedikit waspada terhadap hal-hal yang mungkin dilakukan orang...

{% macro do_stuff(ns) %}
    {% set ns.foo %}bar{% endset %}
    {% set ns.bar %}foobar{% endset %}
{% endmacro %}

{% set ns = namespace() %}
{{ do_stuff(ns) }}

Sebenarnya, saya pikir blok baru seperti {% namespace ns %} akan lebih baik untuk mendefinisikan satu daripada yang dapat dipanggil - variabel bernama namespace tidak terdengar seperti sesuatu yang sangat tidak mungkin diteruskan ke template, dan sementara itu mungkin hanya akan mencegah Anda menggunakan fitur namespace di templat itu (seperti membayangi builtin di Python) rasanya agak kotor ...

Apakah Anda memiliki solusi untuk masalah ini atau apakah kami harus menunggu previtem/nextitem di 2.9.6?
Beberapa templat tumpukan garam saya rusak sekarang.

Seperti yang telah ditunjukkan pada berbagai tingkat di atas, Anda bahkan mungkin tidak perlu melakukan apa yang Anda lakukan. Jika tidak, ya, Anda harus menunggu jika ingin menggunakan 2.9. Itu tidak pernah didukung sebelumnya, kebetulan berhasil.

Kami tidak akan kembali ke perilaku lama. Meskipun berhasil dalam kasus sederhana, itu tidak benar dan tidak pernah didokumentasikan sebagai didukung. Sementara saya mengerti bahwa ini adalah perubahan yang melanggar, itu terjadi dalam rilis fitur (perubahan angka kedua) yang merupakan cara kami selalu mengelola perubahan ini. Sematkan versi hingga perbaikan dirilis jika Anda harus tetap mengandalkan perilaku lama.

Mengunci ini karena semua yang perlu dikatakan telah dikatakan. Lihat #676 dan #684 untuk perbaikan yang sedang dipertimbangkan.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat