My Panel Wishlist

my wish: image cropping added to the image preview. cropped images is generated like a thumb and served instead of original. so original can be restored. would be a major help for some of my less experienced end-users.

1 Like

My wishlist:

  • Give the header a fixed position and put the save button on it, so that you have it in your viewport no matter how long your page form gets
  • A video preview would be great
5 Likes

I don’t want crop in the image preview

I don’t want the image preview to turn into an image editor. I think the thumb automatic resize and crop is fine. Else it’s so easy to to add to much UI panel stuff like…

  • Flip
  • Rotate
  • Color adjustments
  • Brightness
  • Frames

…and so on. I don’t want Kirby to turn into Photoshop. Even if starting with just a few editing functions, I think it’s easy to spend too much time on that instead of awesome core functions. We already have plenty of tools for image manipulation.

What I think is a bad example

I just saw that WordPress developed a favicon editor:

My first thought was… why?? Of all the things they could do with a 100 developers they deside to develop a favicon editor? After reading that I went back to Kirby.

4 Likes

I’m all for keeping Kirby core lean, but I wouldn’t dismiss any feature as “useless”. Anything is perfectly fine as contributed modules, they won’t bloat Kirby.
A big difference between Wordpress and Kirby is that the former tries to empower non-technical people to create their own website, while the latter I think is more intended for “web builders” to create websites for end users/clients (or their own website). For the people Wordpress targets, a favicon editor is fine and makes sense (the similar contrib plugin “All In One Favicon” has 200,000+ active installs, even though it hasn’t been updated in 2 years…)

I think our goal as website builders is primarily to make things easier for users/editors, not for ourselves. If there is really a need for color adjustments or Word import that makes sense for their workflow, then let’s do it (in contrib).

Back to the topic, I would actually love to see more cropping features for Kirby:

  • in core with an option to position the crop ; at least top, right, bottom, left. I believe the “top” option would be the most useful, to avoid cutting heads in pictures of people.

  • a crop module with real-size preview. Much easier for editors than cropping in a graphic app, with much more reliable results (users never follow guidelines, right?).
    Example from a Drupal site I built:

  • a focal point module, very useful in this age of responsive images with multiple sources at different height/width ratios. You just move the focal point to the most important part of the picture, and you’re guaranteed it won’t be cut when the thumbs are created. I’ve worked on many websites at Le Figaro with such a solution. For a newspaper/magazine site, cutting heads in photos is a big no-no :wink:

4 Likes

Focal point is (or rater, should become) a biggie if #perfmatters, but of cause we can always try to learn our clients and editors Photoshop, to take care of both mobile and desktop crops and what THAT even is, instead (haven’t been working out too well, the last 5 times I’ve tried though) :stuck_out_tongue_closed_eyes: So I’m definetely with you on that one :+1:

You don’t need to learn them Photoshop. I made a quick search for image cropping online and maybe this is good for that need (untested)

https://croppola.com/

It even use some magic formula to find the best composition. There are many others working different. Some enhance colors, some give rounded corners as well.

Lots of comments here!

My wishlist:

  1. Better searching - so I can type “huxley” into the search bar instead of “writers/aldous-huxley”

  2. Native WYSIWYG text editing (I don’t want to tell clients that they need to learn markdown, the whole point of using Kirby is that I can quickly build something tailored to their needs)

  3. A way to create alternate views for different types of pages. For example, for pages that serve more as sections than actual pages (like this), it would be ideal to remove the “page settings” tools, and display subpages in a paginated form (like the ‘edit pages’ area).

  4. Smarter blueprints - the possibility to use a PHP file instead of YAML to define fields. This could be similar to something like form helpers in codeigniter:

// site/blueprints/writer.php
<?php

$blueprint_settings = array(
  'title' => 'Writer'
  'pages' = 'false'
  // (or)
  'pages' = array (
    'template' => 'fiction, nonfiction, poetry'
  )
)

echo kirby_field('title', 'text', 'Author Name');
echo kirby_field('cover_image', 'select', 'Cover Image', array('options' => 'images', 'width' => '1/2'));

if ($user->role() == 'admin') {
  echo kirby_field('bio', 'textarea', 'Bio', array('help' => 'You are an admin and can edit the bio'))
}

foreach ...

// etc..

The above was only thought out on the spot, and may be difficult to implement.

In the end, if the panel were as flexible to build out as the front end…

@SQBiz

  1. I agree with you, that a better search would be great!

  2. There’s a plugin for that: https://github.com/storypioneers/kirby-wysiwyg

  3. There’s a plugin for that, too: https://github.com/flokosiol/kirby-subpagelist

  4. I don’t agree with this. I like the YAML-Style because you can define your fields super fast without any ()$=={} hassle.

1 Like

@flokosiol

re: 2. yes, but it’s still buggy and a native version would have more support and development.

re: 3. I hadn’t seen your plugin, I like it! But, what I’m talking about is a built-in way to develop custom views (or templates) for the panel on the fly, without the need to build a plugin.

re: 4. YAML would still fly, but an additional PHP option would be great for when more complicated logic or access to variables was needed.

I generate one blueprint on the fly on my site. Those pages uses data from an external API and I want the page and the blueprint to be dynamic to that.

I simply replace the blueprint file with new data. I would like it to be even more static and renamed from .php to .yaml.

@Christopher the widgets actually worked well, I thought I shared code further up the thread you shared. However, I had struggled to get the custom fields to get recognized from both /site/fields as well as /site/plugins/pluginName/fields because I wasn’t very familiar with the methods @bastianallgeier used to combine them into the other existing fields and overwrite them.

yup, I got everything to work as well, though my requirements were very basic (essentially putting static HTML into a box that appears on the panel) so I can’t speak to custom fields etc.

re 1.: This would be really nice. The search is currently very basic.

re 2.: I don´t want native WYSIWYG. I think it´s bloat (only my opinion). But I use the visual markdown editor by Jonas to make it easier for my clients.
To explain this: I don´t think, that WYSIWYG really exists, without editing in the real page. There are many Problems with this therm, because it´s nearly never the thing you will get on your page (or it will be a really complicated editor).
With kirby every text is stored as markdown, so not everything is possible. Perhaps I´m comparing this to editors of other CMS too much, where you can change nearly everything, including the font. I thinks that this it not a thing, a web designer (and also the client) wants.
Another Problem is, that these editors can be really ugly when copy pasting text from Word or other programs. At a website there is a clear design and the formatting options of markdown are enough in most cases.
But what I do like are editors, which highlight and format the markdown text, that you see what the markup archives. (like visual markdown). Perhaps even as the plugin mentioned by @flokosiol. But I don´t like calling them WYSIWYG.

I think, that kirby and the panel should be a solid basis for everyone´s needs, but it should only be a basis, which everyone can configure for the special needs and add things with plugins.

I tried that editor but for me it was very buggy. I like the idea but not the result. At least until something really works outstanding, just keep it as a plugin and continue with current Markdown in the core.

Some editors use lots of javascript as well and make the admin really slow. That is not what I want. WordPress has a slow admin. Don’t take Kirby there too.

@jenstornell A little off-topic but, may I ask what you find buggy about the Markdown plugin?

Much of the bugs felt random.

  • Sometimes it was loaded to the textarea, sometimes not.
  • Sometimes it was loaded to the first textarea but not on the second.
  • Sometimes it did not resize the textarea and sometimes it did.

With the built in markdown I’ve never had any problems with anything.

I once asked to have a live preview when writing the markdown but I don’t know if anyone liked that idea. Like this forum.

Definitely +1 for a better search!

1 Like

Cropping is already included in Kirby and isn’t really the problem here - But I get where you’re coming from my friend, and like you I like to write code just as much as i love to remove it. So with that out of the way.

Responsive images

The single most important thing you should care about today on the modern web (seriously -if you care about the web and users using it, at all! :smirk:)

Just set dem 2x-Descriptors and sell it

Well, not really, I actually see devs either not really getting or testing this stuff, creating anti-patterns by only accounting for resolution and only using the (currently wider supported) x-descriptor, leading to even worse performance issues for users on mobile.
But full support for the w-descriptor is expected to land in Safari 9 on iOS and OS X (maybe as soon as in the beginning of September), according to this tweet from the Responsive Images implementor for WebKit himself, Yoav Weiss:

The best way to explain the problem and why we might need to attach a Focal Point or Entropy to images through the panel -is to let Yoav Weiss explain the use cases for these native html features a bit better, here goes:

So today we have three Responsive Use Cases, natively tied to srcset, sizes and the picture element

  • Fixed Dimension Case
  • Variable Dimension Case
  • Art-Direction Case

But we’re currently only accounting for the Fixed and Variable Dimension Case in here, unless you’ll degrade the use of the picture element and some parts of srcset and sizes to designers and devs, which I don’t think was the entire point if you’re having a panel which entire and only point is to make all this stuff easy for those who isn’t.
But a Focal Point could give back the power of code to the dev and what’s important about the picture, back to the user.

Introducing: The new complex javascript “Poke Image To Select Point of Interrest Nav Thingy 3000 (Poke twice for rounded corners and frames)”.

Not necessary, although it could include an exciting mathematical problem or three for @bastianallgeier and team, and make Kirby the magical modern and minimalistic CMS of choice -setting the Image Entropy could probably be done with some kind of AI behind the scenes like they do on The Grid maybe with the ability to overwrite it in the backend somehow (as long as it works on mobile) and used as a simple resizeAndCrop($width, $height);

Although i really wouldn’t mind kirby shipping with it, it could of cause also be a subject for a seriously great kirby plugin, to solve this native html problem for regular users using the panel, of cause :wink: Here are some great starting points

Just because it’s new, doesn’t mean it isn’t important and already solved -more often, the complete opposite. :vulcan_salute:t2:

Turns out … it wasn’t that complicated.

2 Likes

about adding cropping to images in the panel image viewer.

I totally agree with you now. Thats why I am creating a new panel field which adds the functionality only if needed.
any help welcome. Changing Toolkit Thumbs Drivers: Scale, Crop