Customize dashboard editing popup for attributes with many fields

Sep 14, 2016

The Problem

Here is a screenshot of a possible situation when editing attributes in the dashboard becomes difficult.

Attribute editing screen making fields inaccessible

The top options are impossible to reach. I wanted to solve this problem and I knew it was easy with some CSS but I didn't want to modify the core. I had to find a way to override the core styling.

Figuring out the Solution

Figuring out the CSS

First I looked at how to do what was needed from a CSS point of view. I did that simply in Chrome's developer tools by inspecting the popup. I took note of its specific class names and how they were used in the core stylesheet

Doing that I figured out what CSS file was responsible for styling that popup. It's concrete/css/editable-fields.css

Use Chrome to find information about the popup styling

Finding out Where and How the CSS was loaded

I wasn't sure whether the CSS file was loaded using the asset system or if it was hard-coded (yes the core team does some weird things sometimes)

I did a search in the concrete folder to see where that css file was called from. I discovered it was registered as an asset in concrete/config/app.php. Line 673 to 675:

'core/app/editable-fields' => array(
    array('css', 'css/editable-fields.css', array('minify' => false))
),

What we learn from these 3 lines of code is that the file editable-fields.css is called as an asset under the label core/app/editable-fields.

This is important so I made a note of this.

Finding a Way to use the modified CSS

I needed a way to add to that CSS file or to load another CSS file to add my styling.

I looked in the developers' docs here and I found the page on registering an asset

Thanks to the information there I went to look into the custom startup file application/bootstrap/app.php and it is full of comments explaining how to do different things including replacing a core asset.

Minimizing Future Impact

One solution would have been to simply take the whole editable-fields.css file, add my styling to it and load my modified file as an asset instead of the original one.

But that didn't seem right as the core team modifies their core styling from time to time (v8 looking at you) and I wanted to habe the smallest impact possible.

I decided to create a CSS file that would do 2 things:

  • Import the original editable-fields.css file
  • add my styling just below the import

The last thing I had to decide on was where to put the file. I knew it had to be in the application folder but there is no CSS folder there so I decided to create a CSS folder inside the application/files folder and put the file there. I also called it editable-fields.css but anything would have been ok.

The Code

In the end this is what I had:

The CSS/Styling

The CSS file application/files/css/editable-fields.css

// Import the original CSS file
@import url("../../../concrete/css/editable-fields.css");
// Add the styling to allow a vertical scrollbar
.editable-container.editable-popup {
    max-height: 350px;
    overflow-y: auto;
    overflow-x: hidden;
}

You can modify the max-height to suit your need and you ca also probably find better looking solution with multi columns and other fancier solutions but this one works and it is solid.

Loading the CSS

I then added my asset replacing code in the application/bootstrap/app.php file

use \Concrete\Core\Asset\AssetList;
use \Concrete\Core\Asset\Asset;
$al = AssetList::getInstance()
// Remember the asset label we noted above? here it is
->getAsset('css', 'core/app/editable-fields')
->setAssetURL('/application/files/css/editable-fields.css');

Something threw me off a little is that in the docs it says:

The path specified in the register() function is relative to one of the following

  • The application/ directory
  • The packages/package_handle/ directory (if a package handle or package object is specified as part of the register() method.)
  • The concrete/ directory

So since my CSS file was in application/files/css and the docs states that the path specified in the register() function can be relative to the application directory, at first I was calling my CSS file like so:

->setAssetURL('/files/css/editable-fields.css');

It didn't work at all and after a little head banging and lots of re-reading I figured out that since I was not using the register() function but the setAssetURL() function I probably needed to make it relative to my root instead so I added the application folder to the path

->setAssetURL('/application/files/css/editable-fields.css');

The Result

With that code in place, when editing attributes from the dashboard the popup height will be 350px tall or less and there will be a vertical scrollbar when needed.

Attribute editing popup with vertical scrollbar

Using the exact same method you probably could style many things differently in the dashboard but I really only recommend it if something is really a problem like we had here.

Recent Tutorials
Generate a report with author information and form summaries in Concrete CMS.
May 9, 2022

In Concrete CMS, you can use a form to initiate contact between logged-in users and then create helpful reports. After form submissions are collected, they can be searched, sorted, and exported as a spreadsheet. This tutorial will detail how to add author information to a report using the advanced search.

How to clone and customize Atomik theme
Feb 14, 2022
By linuxoid.

How to clone and customize Atomik theme

Update jQuery to 3.5 on Concrete CMS version 8.5.x
Dec 1, 2021
By hissy.

If you have to take some time to fix your site to work with version 9 and want to update jQuery immediately, you can override it.

Add-On Developers: Get Your Add-Ons Ready for Concrete CMS 9.0
Aug 6, 2021
By andrew.

Concrete CMS 9.0 is coming! But there are some changes in version 9 that might affected your add-ons and themes. This document aims to answer questions about the most common ways that your add-ons might need to be changed, and common problems you'll run into.

Permissions for editors in a multilingual site
Jun 2, 2021
By myq.

How to set up a multilingual Concrete CMS site for groups of language-specific editors

Getting Started with Doctrine in Concrete CMS
Jan 20, 2021
By linuxoid.

Doctrine is a very flexible, simple (once you get to know it better) and powerful PHP library for database interactions primarily focused on the ORM = Object Relational Mapping and DBAL = DataBase Abstraction Layer.

Was this information useful?
Thank you for your feedback.