Upgrade to v1 breaks with applications using Bootstrap 4.6 about administrate

[nickcharlton]

@januszm, I think you're hitting a few things here, one of which was a mistake by me.

• Could you describe in more detail what custom modifications you're making with the view templates?
• We don't use Bootstrap, we have our own small CSS framework in Administrate itself,
• The search input issues were probably caused by #2492 and fixed in #2512,
• How does the Datepicker fail? Just not load at all?

Could you try with current main and let me know what's still broken?

[januszm]

@nickcharlton thanks for your quick reply, let me clarify this as I was already able to resolve issue 1.

First, problem with template from 0.19 that was customized, and below are diffs that solved it:

- ... ) if valid_action?(:edit) && show_action?(:edit, page.resource) %>
+ ... ) if accessible_action?(page.resource, :edit) %>

(valid_action? => accessible_action?)

- <% page.attributes.each do |attribute| %>
+ <% page.attributes.each do |title, attributes| %>

this is I believe what caused the no method error name for [...] Array, (attribute vs attributes)

Search box with weird blue background on hover (see attachment)

Datepicker actually WORKS but it uses white font color on white background which of course makes the text invisible and suggests that it isn't working. (see attachment)

[januszm]

@nickcharlton also, the last two (visual) issues are solved on the main branch. I've just updated the gem and it looks good.

So the potential, future "Upgrade to v1" Guide should contain information about the need to re-generated the customized partials and re-apply added code. I think that's all.

[januszm]

One more request, I noticed that after the upgrade the <pre> elements don't have white-space pre-wrap set anymore. I have some dashboards where I dump jsonb data with JSON.pretty_generate. It produces <pre> tags (just a poor-mans way for supporting jsonb with administrate). In 0.19 long lines were nicely wrapped. In v1 I have to somehow inject pre { white-space: pre-wrap; }

Or, can I somehow enforce applying this class to specific field?

.preserve-whitespace {
  white-space: pre-wrap;
  word-wrap: break-word;
}

https://github.com/thoughtbot/administrate/blob/main/app/assets/stylesheets/administrate/components/_attributes.scss

[nickcharlton]

So the potential, future "Upgrade to v1" Guide should contain information about the need to re-generated the customized partials and re-apply added code. I think that's all.

Alright, cool! I'll add a mention to explicitly call that out in the migration guide. It is something we started highlighting in the CHANGELOG, but that's always easy to miss.

[nickcharlton]

Re: <pre>, can you tell if that's something that changed in the linting PR? If it was, I think we should undo that specific change as it wasn't intentional.

[januszm]

ReL <pre>, for a regular field it looks ok, both white-space and word-wrap attributes are set properly.
In my case the issue is with a custom field (data type) that I called PrettyJson (it's a type that I use to dump a typical jsonb column data).
It generates the following css class which is missing the necessary white-space attr attribute-data attribute-data--pretty-json-field

[januszm]

UPDATE: @nickcharlton please disregard my comments about <pre>. After all it was because I had a custom field with a custom template and in that template I used <pre> tag. The solution was to add a CSS class to this custom view partial.

Any chance I can tell my custom field class to use preserve-whitespace CSS class on the generated element? Just like for the Field::Text class.

[nickcharlton]

Ah, hah! Excellent. Glad to hear you figured it out.

Is that everything you were having trouble with?

[januszm]

All good now.

I'd make this section of the migrating .md file a bit more detailed, e.g.

As with most upgrades, if you're upgrading between versions with changes to the
templates, and if you've customised them, you may need to apply recent changes.
You can see those which changed in the [CHANGELOG][].

This applies to both modified files in `app/views/admin` and `app/views/fields`
if you have your own Field classes defined. A good way is to use the same command
to generate the view as for the earlier version:
`rails generate administrate:views:ACTION MyModel`
noting the changes and re-applying the modifications

[nickcharlton]

Oh, yes, that's a great idea. I'll do that.

I'll close this now, but please open new issues if you find problems.