Backpack repeatable field not working on Azure instance, but works locally

[kerwin-wildsea]

I have a page with a repeatable field. On my local machine it's working perfectly, but on the host machine (Azure instance) it shows the following:

While it locally looks like this (as expected):

---

The code:

CRUD::addField([
    'name' => 'sequence',
    'label' => 'Vragenreeks',
    'type' => 'repeatable',
    'subfields' => [
        [
            'name' => 'question',
            'label' => 'Vraag',
            'type' => 'select2_from_array',
            'options' => $this->selectableQuestionOptions(),
            'allows_null' => false,
            'default' => 'one',
        ],
    ],
    'new_item_label' => 'Vraag toevoegen',
    'init_rows' => 5,
    'min_rows' => 1,
    'max_rows' => 50,
]);

My findings and what I've tried so far:

• The result of $this->selectableQuestionOptions() is valid and correct according to the docs
• Move the select2_from_array type outside of the repeatable , then it shows the proper dropdown (so backpack pro works)
• Changed the select2_from_array type to text or select_from_array inside the repeatable, then it also doesn't show anything
• No errors on either the laravel, console dev tools or networking (network tab in dev tools) side
• Copy pasted the repeatable example from the docs, also doesn't show any content inside the repeatable blocks

I'm mainly wondering, what else is there to test? It works flawlessly on my machine but not on the Azure instance. Backpack Pro is working fine and everything else (all other pages) do work as far as I can tell. Though, non of them have a repeatable field like this one.

Any help is appreciated!

[pxpm]

Hey @kerwin-wildsea any errors on the console, some file failed to load?

My first guess would be that some required JS is not correctly loaded, or somewhere else a js error is triggered.

Let me know.

[kerwin-wildsea]

@pxpm Yes, all screenshots currently are from a staging server which completely resets on deployment so I am free to mess with it. That being said, it probably has to wait until tomorrow (EU time). But if you have specific things you'd like to know, I'll do it first thing in the morning!

Also, thanks once again for taking the time! ❤️

[pxpm]

No problem, hope we can figure out the root issue 🙏

I really don't know atm., probably put some @dd() and @dump() around the lines I mentioned to try to figure out if the code is reaching there or something similar.
I've never used azure, but I never saw anything like this happen in any other provider, so yeah, we are shooting in the dark here.
Probably also worth to check logs files in storage/ if something is being dumped there that could help us.

Let me know tomorrow after your tests what you tried, what was the output and maybe we can come up with some other testing ideas if we can't identify the issue.

Cheers, see you tomorrow 🙏

[kerwin-wildsea]

Hi @pxpm,

I started debugging (using: @dump($field)) in the file you requested both locally and on Azure to make sure I knew what the expected outcome was and quite quickly ran into interesting results... Locally it printed the field fine but the dump does not print at all in the repeatable.blade.php on Azure. At first I thought it was a page caching issue but then editing: vendor/backpack/crud/src/resources/views/crud/fields/text.blade.php does work and I do see the field content.

I'm quite lost how I do see 5 'blocks' which indicate the field is repeating itself, but no dumps in the repeatable file itself.
Although, I do not exactly know how it works. I'll keep digging for now 🙂 This is a great start

---

Note: I'll keep updating this comment until you've responded as to not spam you with new comments

---

Edit1: Alright, so I added dump($fields) in vendor/backpack/crud/src/resources/views/crud/form_content.blade.php:1 and the result was as expected and the same as it is locally (other options in the select2_from_array but besides that same result):

array:3 [▼ // vendor/backpack/crud/src/resources/views/crud/form_content.blade.php
  "type" => array:8 [▶]
  "name" => array:4 [▶]
  "sequence" => array:9 [▼
    "name" => "sequence"
    "label" => "Vragenreeks"
    "type" => "repeatable"
    "subfields" => array:1 [▼
      0 => array:8 [▼
        "name" => "question"
        "label" => "Vraag"
        "type" => "select2_from_array"
        "options" => Illuminate\Support\Collection {#1740 ▼
          #items: array:7 [▼
            "select" => "-- Selecteer een vraag --"
            "random" => "Willekeurige vraag (automatisch)"
            1 => "Vaste vraag: Waar staat AVG voor?"
            3 => "Vaste vraag: dit is een nieuwe vraag"
            4 => "Bonus: STUDENTEN: Je krijgt een mail binnen die je niet vertrouwt, wat doe je?"
            10 => "Vaste vraag: Je ontvangt deze mail, wat doe je?"
            11 => "Vaste vraag: Nam ullam sunt asper"
          ]
          #escapeWhenCastingToString: false
        }
        "allows_null" => false
        "default" => "one"
        "parentFieldName" => "sequence"
        "entity" => false
      ]
    ]
    "new_item_label" => "Vraag toevoegen"
    "init_rows" => 5
    "min_rows" => 1
    "max_rows" => 50
    "entity" => false
  ]
]

---

Edit2: More progress! So I added:

@dump($crud->getFirstFieldView($field['type'], $field['view_namespace'] ?? false), $field)

to vendor/backpack/crud/src/resources/views/crud/inc/show_fields.blade.php. Locally this is as expected: backpack.pro::fields.repeatable and the field data. On Azure this somehow becomes: crud::fields.repeatable and then the field data...
Which explains why the dump in the field didn't run at all.

---

Edit3: I looked through the code, and found ViewNamespaces::getFor('fields') in vendor/backpack/crud/src/app/Library/CrudPanel/Traits/Views.php. I logged it and it resulted in the expected:

array:2 [▼ // vendor/backpack/crud/src/app/Library/CrudPanel/Traits/Views.php:304
  0 => "crud::fields"
  1 => "backpack.pro::fields"
]

After that, I added multiple dumps on the following lines (same file) 306-312:

dump(backpack_pro());
foreach ($paths as $path) {
    dump($path);
    if (dump(view()->exists($path))) {
        return $path;
    }
}

Which resulted in this for Azure:

"2.2.4.0" // vendor/backpack/crud/src/app/Library/CrudPanel/Traits/Views.php:306
"crud::fields.repeatable" // vendor/backpack/crud/src/app/Library/CrudPanel/Traits/Views.php:308
true // vendor/backpack/crud/src/app/Library/CrudPanel/Traits/Views.php:309

Locally the crud::fields.repeatable returned false. So it is finding a view which shouldn't be there?

---

Edit4: (Found the reason....) (See accepted answer)

[kerwin-wildsea]

Alright, so I did: ls -la vendor/backpack/crud/src/resources/views/crud/fields/ as the code is suggesting this view exists...

...

...

Well, that ought to do it. Azure somehow does not clean the previous files from the vendor folder or something like it...
I assume this is from a previous release as the file is from 2022. I'm going to look into this further.

@pxpm Thank you so much for getting me on the right track. I had no idea where to start until you sent me the initial view file.
Also thanks for responding to these 'random' support tickets. Much love ❤️

[pxpm]

I am very happy that you found the issue 🥳 , that was a very good debug session you did there, hats-off 🎩

I think you probably should investigate that, maybe someone manually added those files there, so they are not "tracked", just lost there ?
Those files should be in vendor/backpack/pro not vendor/backpack/crud. It's possible that you will have similar issues with relationship I see in the screenshot, so I'd suggest you remove that one from there too, as it should be present in vendor/backpack/pro/resources/views/fields (please confirm before proceeding).

Appreciate your kind words ❤️

[kerwin-wildsea]

@pxpm If someone added those manually it was before my time on the project.
For now I've just rm -rf'd the entire vendor folder and redeployed the app which generates it again.

Azure is supposed to clear the entire project folder on redeployment by default as we had to explicitely add persistent storage for uploads etc. not to be cleared (according to system manager) but this seems to suggest otherwise...

[pxpm]

You can always check again next time you update dependencies, see what we changed in backpack crud or pro, and check if those changes are reflected in your project.
It may have been a temporary issue, or something that will happen every time you deploy 🤷

Cheers