The Backdrop community is proud to release version 1.15 of Backdrop CMS, following our 4-month release cycle. We'd love your feedback on this release.
Major new features in Backdrop 1.15.0 preview include:
- #3297 Add Image Library modal to Image fields
- #3566 Add a recent news block to the dashboard
- #1610 Allow content to be placed into the menu by default
- #4200 Allow menus to be always click/touch activated (rather than hover activated)
- #3972 Add new translatable HTML5 date form elements: html_datetime, html_date, html_time
- #4235 Add more display options for boolean fields
(See our discussion of v 1.14)
Comments
I guess this is really on 1.14 but we are just now working with the new flexible template builder UI. These kinds of tools are helpful for us, because the sites follow a model of developer creation and admin user modification. When they can tweak the site - especially what it looks like - directly, without having to request a code file change, my users are much happier.
If we have suggestions/requests, should we add them to the meta followup issue https://github.com/backdrop/backdrop-issues/issues/4046 as comments? Or better to create new issues?
You could do either. My recommendation would be to create a new issue first, then if you are so inclined you could link to it in the meta issue. However, your request/suggestion is more likely to get attention (in my opinion) if you open a new issue. It's a good idea to look for an existing issue first, before opening a new one.
People should be very comfortable opening issues or feature requests in the Backdrop CMS core issue queue. https://github.com/backdrop/backdrop-issues/issues
The issue queue gets a lot of attention from core developers and we're usually very eager for feedback and ideas.
I also found that because I was updating through the web UI, I wasn't getting changes to files outside of core. This came up because the trusted host always showed up as not configured in the status report. It's a little bit of an issue because I had hoped that the main users of a site would be able to keep it up to date, without direct access to the server. There was no indication that there were changes we were missing out on.
Relatedly, files that were removed from core were still there on our site. I imagine most of the time that won't matter, but it might need to be something to check for if it ever does.
I have seen some (sFTP) client software leave files behind when you are copying over existing ones. In other words, they overwrite existing files, but if a file does not exist in the source (the new version you are trying to update to), then the file in the target will not be touched.
What I could try is to delete the entire core folder from the server first (please take backups before you do anything destructive like that!!), and then copy over the core folder from the fresh version of Backdrop.
Here's the easiest and at the same time safest way I would go about upgrading from say 1.14.2 to 1.15.0:
Doing things that way effectively keeps a backup of the old core folder on the server; so if something happens to go wrong with the upgrade, you revert to a copy of the db before the upgrade -> rename the
corefolder back tocore1150-> rename the backup foldercore1142tocore-> done!I hope that the above makes sense ...and remember: back everything up ...at least in 2 different places!! :)
For the records, (and a little late) after reading your comment, I opened an issue for that
I agree, we should take care of those files, although they don't do harm.
FTR: This is the issue where the trusted hosts feature was discussed and implemented: https://github.com/backdrop/backdrop-issues/issues/2568
There have been comments about making it possible to configure this via the admin interface, and there is a related ticket here, where we plan to introduce a dedicated "Security" section in the admin backend. In the summary of that ticket, there is a bullet point about allowing trusted host patterns to be configured there; so this is on our radar (although it may turn out that it is not a good idea, and it may not be implemented after all). Please follow that issue for more updates :)
In general, I think that we have done a good job in making this feature much less "intrusive"/strict than the D8 implementation.
I'm coincidentally working through a series of changes coming out of beta testing of a client's site, and the lack of an equivalent to Display Suite or some other UI-based way to rearrange the exact details of how things look continues to be the biggest sore spot. A direct quote: "I haven’t tried. To be honest, most of working with BackDrop seems pretty obscure to me compared to Drupal."
Hmm, I was under the impression that our Layout system was meant to be used as a replacement for the Display Suite module.
Perhaps certain things are still missing before we achieve full feature parity (as much as possible). If there are such things that you are missing, which are blocking your work, or making it considerably harder to build sites using Backdrop, then please open a feature request, and provide as much details/info as possible.
Our layout system covers some of what display suite does in obvious ways. Things like custom field placement is available through the layout system, but I find it a relatively hidden feature that many users will miss.
We have someone that recently started a port of the remaining features of the display suite module. It might not hurt to post an encouraging note here:
https://github.com/backdrop-ops/contrib/issues/392