If all you need is the actual tweak, you can skip straight to the configuration part.

Why this became necessary

On my friend links page, I use Butterfly’s built-in flexcard layout. Each link is shown as a card: avatar on the left, then the name at the upper right and the description below it. When the mouse hovers over a card, the right-side content shifts left, pushing the image away so the name and description move further forward.

That interaction works fine at first glance, but on regular desktop layouts—more precisely, on any screen wider than 1200px—the theme displays three cards per row. Once that happens, some longer descriptions no longer fit properly, and even longer names can end up partially hidden.

The earlier workaround

The first time I ran into this, the problem was triggered by IT侠’s description:

“侠之大者，为国为民；侠之小者，为友为邻。”

A card that only takes up one third of the row is simply too narrow for text like that, and forcing the whole sentence onto one line looked awkward anyway. My temporary fix was to insert a <br> in the middle so the paired phrases could sit on two lines.

Why that stopped being practical

As more and more friend links were added, the same issue started appearing on other cards too. And for descriptions that didn’t have such a clean natural break, I would have had to keep manually testing where to place <br> tags. That quickly became annoying, and honestly, it was not an elegant solution.

So one afternoon I decided to dig into the friend links page and fix it properly.

Looking for a built-in setting

The first instinct was to check Butterfly’s _config.yml for a relevant option.

There wasn’t one.

The second instinct was to search for a tutorial.

That did not help much either. Most results only covered the absolute basics, like how to create a friend links page, while others were much more aggressive full-theme modifications than what I wanted. The one post that looked promising turned out to be a 404.

At that point, the only real option was to open the Butterfly theme files and see whether the source itself could be adjusted.

Where the layout is controlled

The relevant file turned out to be:

/themes/butterfly/source/css/_page/flink.styl

Inside it, this section controls the width of each friend link card:

& > .flink-list-item
  position: relative
  float: left
  overflow: hidden
  margin: 15px 7px
  width: calc(100% / 3 - 15px)
  height: 90px
  line-height: 17px
  -webkit-transform: translateZ(0)
  addBorderRadius(8)
  +maxWidth1024()
    width: calc(50% - 15px) !important
  +maxWidth600()
    width: calc(100% - 15px) !important

It is easy to see why there are three cards per row: the width is set with 100% / 3.

So the most direct fix is also the simplest one—change that to 50% so desktop screens show two cards per row instead of three.

Letting descriptions wrap naturally

Scrolling further down reveals another useful section:

.flink-item-name
  @extend .limit-one-line
  padding: 16px 10px 0 0
  height: 40px
  font-weight: bold
  font-size: 1.43em
.flink-item-desc
  @extend .limit-one-line
  padding: 16px 10px 16px 0
  height: 50px
  font-size: .93em
.flink-name
  margin-bottom: 5px
  font-weight: bold
  font-size: 1.5em

From the names alone, the roles are fairly clear:

• flink-item-name controls the style of each friend link name
• flink-item-desc controls the style of each description
• flink-name appears to control the group title styling

The key part here is @extend .limit-one-line, which forces the text to stay on a single line and, when necessary, cut off with an ellipsis instead of wrapping.

For descriptions, that behavior was exactly what I did not want. So I simply commented out the single-line rule in .flink-item-desc by adding // before it. After that, the description could wrap naturally.

With those two changes together—wider cards and no forced single-line description—the layout became much more usable, especially for longer descriptions that previously had to be manually patched with <br> tags.

A small note at the end

This tweak did not rely on AI at all. Maybe the task was just simple enough that opening the stylesheet directly was faster than asking for help.