240 replies to this topic

[Soma]

Ryan, well, it's actually everytime I add a new element enter something and save it first time, I get the soft page lock. After that saving is normal, until I add new element. I have latest PW and nothing special installed , and also deinstalled couple and still same. Also tried different fields each time. Seems an issue in combinations with user data that is handled by my "PageEditSoftLock" module.

Could you if you have time take a look into what could cause this? And if you can reproduce.


Something else:

[ryan]

Soma thanks for all your testing. I hope to test, reproduce and resolve the issues you've mentioned tomorrow morning, and then post a new update.

Thanks also to Statestreet, Diogo, Seddass and Biotech for the testing and feedback.

2/4 |========[]========| Columns: [ 4 ▼ ]

Compliments on this diagram, quite cool. While I need to retain the ability to have columns of different lengths, I do think this would be perfect if we were sticking to columns of the same width.

I'm still getting sometimes this error message that another "me" user currently is editing this page!

I should be able to figure it out when I test tomorrow.

BTW it would be somehow be cool to update the #index when dragging an item. I think it could make sense since it isn't saved anyway. Though It may would be even cooler to have a title somehow "name" shown in the bar, that is recognized when collapsed not just #1,#2,#3.

Showing the title in the bar is something I'd like to do, it will be coming. But will just require that the repeater has a title field (title fields aren't required for repeaters).

Label not translated. Bug?
Ryan. The label of the repeater field the one you can drag, doesn't show me the german label..

It's just not yet language aware in that regard. I'll add that in on the next update though.

Something else:

Beautiful!

[statestreet]

assume that all colums are equal do you? screen shot show columns, lengths different

Quite the opposite, actually! That's one of the benefits of this approach—you set the divisions to, say, 8, then you can have one field that shows up five times in a row and is set to 1/8, then one field that shows up once and has the slider set to 3/8.

Anyway, not to get hung up on this; I just like adaptively granular controls.

[apeisa]

Very cool stuff Ryan. We will be moving to the new house this weekend so I don't have very much time currently. I can't wait to start building sites with all these great features available.

[Soma]

Ryan. Something that just hit me hard. While thinking all the time about these columns, setting them up makes just clear that the implementation is on the wrong level. It should be something to define on templates level to keep re-use ablity alive as much as possible and separate structur from the data as long as possible. Having "editing mask" layout setting on field level seems just wrong to me. I hope you proof me wrong.

I really think it would make it a lot better if these information would be held on template level or in this case the repeater field group. While I think a good implementation would go very far regarding "interface" with some kind of editor with drag and drop, defining columns, but surely something possible. But maybe just having some sort of a text inputfield along each field in the drag bar to enter a % number could do the job in its simplest form.

I'm really loving what you've doing here, just wanted to give my honest feedback. While I've had my wow moments (dancing in the kitchen) while playing around with all these stuff, I'm looking a little closer and try to look at all the different aspects.

[ryan]

Soma I think there's multiple ways to look at it, but I'm not too enthusiastic about getting the templates involved in individual field settings. That seems like blurring the line about where things are defined, leaving one to guess where they would define one thing or another. This is when software gets complicated. Would you really want to define the width of the field in the template and then the type, size and maxlength with the field? These things are all related and shouldn't be separated in my mind. Templates aren't supposed to know anything about fields other than which ones they have. I do think about this stuff a lot before coding it. I also appreciate exploring this from all angles, and that's why I'm very glad to have you involved in this project. Your viewpoint is always valuable and well thought out.

Consider how we work with markup. When you define floats, the container doesn't decide the proportional width of the floats--the floats do. When we define the type, size and maxlength of a field, we define it with the field, not the container. If a field is suitable for use in a narrow column, that's got to do with the type of field that it is and how you've configured it. This is the field's data.

Reusability is far from black and white here. If you've setup a field for reduced-width use, shouldn't that remain consistent regardless of whether you are using it for columns or not? There's more than one reason to set the width of a field. Another consideration is that if we start defining field widths with the template right alongside the fields, people will think this is something rather important. I don't want people to think they have to use this. It's a nice optimization, and far from a requirement. If this were particularly important we would have had it a long time ago.

Where I like your idea is as an add-on or override at the template level for the power-user. The field still defines its width, but you have the opportunity to override it in the template. That way the field still owns the data it should, but the template can see that and choose to override it. If you only wanted to define it at the template level, then you could. I want to hide the details of that by default so as to avoid confusing what is template data and what is field data, but give the option to the power-user. So I'm thinking an optional module or setting one can turn on if they want to define it at that level (and sliders would be particularly fun here).

[Soma]

Thanks for your reply! My thinking is a little different than yours it seems.

I actually think it would simplify a lot. To define the layout mask of the template on the template itself and not on the field. Width is actually something related to the template mask the field will be put, I don't see this same as the other field settings.

Also regarding re-usability of the fields. This would have effect on how fields can be used across different templates, I don't want to have multiple "title" fields just because one I want one 50% and the other 100%...

This way (defining on template level) it wouldn't make it more complicated, but as it is now, it's actually getting complicated: to maintain, to setup and to trace...

Whereas when defining such things on template, would require one look and one place to edit these widths. As it is now, I can't see what field has what width and makes it hard to keep track of it.

As you say there's different views on this particular subject, but I'm sure I'm not alone on this.

I think having the possibility to overwrite the width setting of a field on template as a option, will make it blurry and "complicated" and it opens traps and confusion. I just have hard time accept in my mind that this would be a good way to get around the problem.


---

Problem report:
When I add a file field with small width, the upload button gets overlayed by the "drop files here"... note in the field, and I can't click it to upload a file.

[diogo]

What Soma is saying makes some sense if we look at it, not only from the perspective of these new fields, but also in general with other fields. I felt the need to define, for instance, the name of one field, differently on different templates several times. I mean... If i want to use the same field, with all the same characteristics, but with only a different name, why should I create another one, and another, and another, depending on the template? What maybe would make sense (could be a module like Ryan suggests), would be being able to override the settings of each field while creating the template. But as I say, this would apply to all field settings, and not only the columns.

EDIT: at same time Soma. Overwriting can make more trouble if you do it on all of them, but if you do it only on some, it makes less trouble. I think it's good to have a default value.

[ryan]

When you edit a field, there is a tab called 'input' and that's where you define the settings related to the input field presented to you in the admin. When you edit a template, you are there to edit the settings related to the template, not the individual fields. Maybe you don't agree with this architecture, but that's the way the system was designed from the beginning and I don't want to cross those concept boundaries until they fit the bigger picture of the system. That bigger picture is called template field context, and that's a feature that's already planned for and something we've been talking about for a long time. But also something that's going to take some real time resources to do well, and it can't be done now. But when we go there in a future version, you'll be able to modify some field settings within the context of the template. Things like title, description and now likely width. But I'm not interested in blurring this line until we have full support for field contexts within templates.

As you know, ProcessWire does not currently support those different contexts for a field on a per-template basis. If you are creating multiple fields just to get different widths, stop doing that. You should not be using field widths in that case--leave it as a normal PW 100% width field like you've always used. These width settings are for when you have a specific need, like a pricing table or something like that. They are not something you should use on every field and not something you should use on fields where you need all kinds of different contexts.

Because PW has always had 100% width fields before yesterday, not every field is going to be a good candidate for reduced width -- Soma the file field probably shouldn't be used at anything less than 50% at present. I would expect there will be other fields that won't be happy at reduced width, though I've not found any yet.

[ryan]

Seems an issue in combinations with user data that is handled by my "PageEditSoftLock" module.

I tested it out with PageEditSoftLock and found the problem. The reason it tells you that another instance of you is editing the page is because of this statement in the checkpagestatus function:

$user = $this->users->get($user_id);
if($user === $this->user){

When a new repeater page is added, it goes through a $pages->save(). After $pages->save() finishes, it clears the in-memory page cache to ensure any future $pages->get/find operations in the same request aren't returning old versions (it has always done this). Users are pages. As a result, your $this->users->get($user_id) is returning a new instance of the current user than what is in $this->user, so a '===' comparison won't work, since it checks to see that two objects are the same instance. But the fix is easy, just change the above code segment to this:

if($user_id == $this->user->id) {

This is also more efficient, as there's no need to retrieve the user from $this->users->get() when all you need is the user ID, and you already have it.

---

Edit: fixed issue with the repeater labels note honoring the language setting. They should work properly now.

[Soma]

Thanks a lot Ryan for testing. I will change that and update the repo of SoftLock module.

[ffub]

Hi Ryan,

Any tips on how to edit repeaters via the API? In particular I'm interested in how to add and remove entries to a repeater field on a page.

Thanks,
Stephen

[leroj]

Awesome work Ryan, mind blowing Can't wait to try this

[ryan]

Stephen, I haven't fully developed the API for this field just yet. But here's how you'd do it at present (and it will get a lot simpler than this). I've written this in the browser so there might be mistakes here, and I can try to test this out later.

// create the new repeater field
$repeater = new Field();
$repeater->type = wire('modules')->get('FieldtypeRepeater');
$repeater->attr('name', 'my_repeater');
$repeater->label = 'Your Field Label';
$repeater->save();

// forces a self-setup + configuration (this is an odd step, I know, will improve)
$repeater->type->getConfigInputfields($field);
$repeater->save();

// add some other fields to the repeater
$repeaterTemplate = wire('templates')->get($repeater->template_id); // get the template used by the repeater
$repeaterTemplate->fields->add(wire('fields')->get('title')); // add title field
$repeaterTemplate->fields->add(wire('fields')->get('summary')); // add summary field
$repeaterTemplate->fields->save();

// add the new 'my_repeater' field to your the 'basic-page' template, as an example
$template = wire('templates')->get('basic-page');
$template->fields->add($field);
$template->fields->save();

Now to jump to another example. Lets say you already have a repeaters field called $page->my_repeater and you want to add a new repeater item to it:

$repeater = wire('fields')->get('my_repeater');
$item = $repeater->type->getBlankRepeaterPage($page, $repeater);

$item->title = 'Test item';
$item->summary = 'This is just a test item';

$page->my_repeater->add($item);
$page->save();

This is all a little complex from the API side in my opinion, so I'll be making this a lot simpler... but just wanted to at least reply with a useful example.

[ryan]

Soma, Diogo: you'll be glad to know I've taken a close look at field template context and how we might support it in the core. It'll be simpler than I thought, so there's a good chance I can get this in version 2.2, relatively soon. Now that I understand how we'll do it, I think we'll be able to provide template context of almost any field setting (custom and internal). So it will likely go beyond just title, description, collapsed, width, etc. To change the context of a field within a template, you will edit a template, then click on a field name or edit icon (in the asmSelect). It'll open a modal window with all the field's configurable settings, all within the context of the template. I think this will be pretty cool.

[Soma]

Soma, Diogo: you'll be glad to know I've taken a close look at field template context and how we might support it in the core. It'll be simpler than I thought, so there's a good chance I can get this in version 2.2, relatively soon. Now that I understand how we'll do it, I think we'll be able to provide template context of almost any field setting (custom and internal). So it will likely go beyond just title, description, collapsed, width, etc. To change the context of a field within a template, you will edit a template, then click on a field name or edit icon (in the asmSelect). It'll open a modal window with all the field's configurable settings, all within the context of the template. I think this will be pretty cool.

Awesome Ryan! This will simplify a lot. You know, I was actually thinking quite a lot of times, that it would be nice and possible, to completely being able to setup fields within the edit template screen directly, and kinda use dialogs and such to edit fields, drag them into the template etc. After first week starting with PW back then, I was even starting to play around in my mind with creating a visual node template editor with raphaël js (brilliant svg) library. I found it would require a lot of experimenting and some better knowledge of PW. Also there's no really good implementation of a visual node (with drag drop connecting and stuff) for raphaël yet, only one more decent and unfinished. So writing one my own first would go a little far and held me up.

Can't wait to get my hands dirty with this new feature and see how it feels! Thanks for your continuous effort to make this the best CMS around.

[diogo]

Wow!! Ryan, PW is getting better too fast!!!

[raydale]

Soma, Diogo: you'll be glad to know I've taken a close look at field template context and how we might support it in the core. It'll be simpler than I thought, so there's a good chance I can get this in version 2.2, relatively soon. Now that I understand how we'll do it, I think we'll be able to provide template context of almost any field setting (custom and internal). So it will likely go beyond just title, description, collapsed, width, etc. To change the context of a field within a template, you will edit a template, then click on a field name or edit icon (in the asmSelect). It'll open a modal window with all the field's configurable settings, all within the context of the template. I think this will be pretty cool.

This all sounds amazing Ryan. Field contexts on a template level will allow so much flexibility in the admin. We can then create ever more usable, custom admin screens for clients - simplifying the editing process for them. I can imagine that it will also keep the number of different fields necessary down to a minimum too?

This is a really exciting development.

[ryan]

Thanks. I agree this does have potential to reduce the number of fields you might need, or at least, allow you to be more specific and contextual with the information you present with the fields. Ultimately it should lead to a better experience either way.

[Christoph]

Just tested reusable fields and I'm really happy with this handy feature as there are so many use cases. Thanks so much for this!!

Two thingsI stumbled upon:
1) I couldn't change the »input field settings« from »always open« to somethings else. It jumps back to the basics tab but doesn't save the change.
2) Is there a special setting to make the output of a repeatable field viewable to users who are not logged in? Currently I only see the output when I'm logged in.