My Panel Wishlist

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

24 posts were split to a new topic: Make title for “Pages” in the Panel translatable

Another suggestion/question:

Do we need this page at all? :

Since Kirby 2.3(?) we can change a subpage’s status on the fly in the status bar. I would suggest to get rid of the edit button for the subpages. Maybe one could exchange it for a “change order” button to switch to a drag & drop mode inside the sidebar.

Related to this I would also make the difference between online and offline pages more obvious. In my experience it is not clear to the clients that subpages with numbers on the right side are online, those with a “-” are offline. Her is my quick approach for this:

A separated edit page however is kind of pointless. The drag and drop interaction is fun to use, but does not really correspond to changing the online/offline state of a page. It would fit better for moving pages between different parents, which would be another point on my wishlist.

4 Likes

Hm, if you grey out invisible pages, it looks as if they were not editable? So I think, separating the pages, yes, but not grey them out.

There is still this issue on renaming the visible/invisible flag. Maybe it should really be renamed to something like sorted/unsorted instead.

As regards the overview page, I agree, it is no longer necessary anymore and integrating the drag/drop functionality into the sidebar is a good idea.

1 Like

You can already grey out invisible items with custom Panel CSS:

.sidebar-list a.invisible {
    color: #999;
}

Keep in mind that that’s how Kirby 1 used to work, and it quickly became a pain to edit once you had more than a handful of subpages. I might be wrong, but my guess would be that that’s the reason why Bastian moved it to a separate page. I guess it wouldn’t harm to add drag’n’drop to the sidebar as well, but I would keep the separate subpage editor available, at least optionally.

4 Likes

@diondiondion You are right, I had completely forgotten about that :pensive: So the drag and drop functionality of the sidebar should really only be an additional goody.

I really like the idea of removing the “Pages” panel page.

However, I don’t like the new “Change order” button.

On drag, change order

To make it super easy, just allow the panel user to drag and drop the order of the pages. There is no need for an activation button, I think.

On click, enter

With click, edit the page. Many systems work like this and it very simple to use.

Like the structure field

I just used the structure field and it works just like that with the style set to table. On drag, order items, on click, edit item.

I’d love a client-specific user role that uses WSYWIG instead of markdown by default

There is a third-party WYSIWYG field for Kirby.
I think you shouldn’t use one field for one role and another for another role though, otherwise the content will be inconsistent. If you as the developer don’t like WYSIWYG, you can edit the content files directly if you want. :slight_smile:

What would be good is if you could see and edit the raw data sometimes. This would allow us to copy and past data without the need of ftp access.

My client has an element that exists on every page more or less in the same way (it has lots of fields and is tedious to fill in). With a raw view of the data he could just copy and past it in, save and be finished without filling in every field again and again.

I don’t want that my client edits the raw files in a text editor and saves them because I bet they will just mess up the server someday and then you got the pleasure to debug that. No thanks ^^

Just out of curiosity, in what way does this element differ? I’m asking because I wonder if there is there no other way to store the content for that element so that it is not necessary to repeat the same stuff all over again.

There are speeches on the page that advertise other available speeches via an image slider. The slider is build by using the structured field builder plugin. Each slide is a structured field entry.

Title: Bildslider Nepal
----
Slider-no-text: false
----
Builder: 
-
  image: wunderwelten_inseln_des_nordens1.jpg
  text: Inseln des Nordens
  link_text: zum Vortrag
  link: >
    vortraege/inseln-des-nordens
  _fieldset: slider
- 
....
..
.

I don’t know how much the sliders will differ through out the whole range of speeches. There might be a lot of the same but they can also be some variation.
For now they have to always go through the process of adding ~8 structured fields and add the (often same) content for each new speech they create.

What would be great if they could paste the raw data from an other slider they created and just upload the missing images and they would be done.

But what you want to do is to clone a structure field item?

Well the slider is no not just a structure field item. You can see it in the blueprint that I posted. The slider itself is a module (so to speak a subpage). In order to “clone” it I would need to copy all of its content and not just the structured field items.

I would imagine something like your splitview plugin. You can toggle between the 2 view modes: raw data and the standard. Then you could copy and paste the raw data or fill it in via the form fields like you would do normally.

But then your raw data view would not have to be a view area only (to copy from) but also a view to paste into, because you can’t simply add the raw data into the fields.

Wouldn’t it be easier to clone the complete page and then only change the bits that need to be changed?

Yes it would be a editable view where you can also manipulate and save the data.

I think cloning a page is also a good option but can also has its flaws when not done right. There is a plugin where you can copy pages and files etc. Page/folder/file copy plugin via a widget. But I don’t belief my client would be able to understand how to enter the right path and destination and I also don’t feel comfortable with that solution. It’s a too complicated imo.
Copy and pasting on the other hand would be something that we are very familiar with which makes it more likely to be used without the fear of doing something wrong or unwanted. There is just no “revert” or “undo” for your actions.

I would love a cloning or copy page feature. But the process of doing that should be very simple and thought out.

I would just create a simple clone field for your specific purpose, I created a field that just copies a page (into the same parent folder) and nothing else (no files, no subpages). Maybe you can use it as a starting point.