PW 3.0.142 – Core updates + FormBuilder v40

[ryan]

ProcessWire 3.0.142 has a lot of updates but the biggest is the addition of custom fields support for file and image fields. In this post, we take a closer look and also outline all of the new features in the just-released FormBuilder v40—

https://processwire.com/blog/posts/pw-3.0.142/

[dotnetic]

First of all: Great additions and exactly what I just need for a project.

But somehow the new custom fields for images and files do not seem to work correctly. I integrated them into an existing PW project and the fields appear for the superuser, and also for other roles... But: the other roles don't see the text that the superuser entered. Then I tried saving a value to a custom field with another user, and the value isn't saved.

So I thought, because I have a complicated setup with many hooks and restrictions that hook into ProcessPage::buildForm I try out the new feature on a completely fresh PW installation. But in the new installation the custom fields don't even appear. Am I doing something wrong? Is this a bug?

Here is a little screencast of my existing project (with audio)

And here is a fresh PW install, where it do the setup process of the custom field, and then it does not show up (without audio):

 

[ryan]

@Jens Martsch - dotnetic Thanks for the videos. Let's focus on your 2nd example first, because I see things in first one that I don't recognize, and it looks like there is access control at the field level too, so lots of factors—let's come back to that one. In your 2nd example (blank installation) you haven't yet uploaded an image into the field, so it doesn't look to me like it should be showing any fields yet. But you are circling something with your mouse, so I'm not sure I understand. But you shouldn't see any of your custom fields if you haven't yet uploaded any files/images yet, so can you try that example again or let me know if I misunderstood? (no need to record it to a video, just wanted to make sure I wasn't missing something). 

[dotnetic]

*Facepalm* I did not upload an image in the second example *ROFL* . It has been 3 long weeks without resting, please forgive me.

After uploading an image, the fields appear. I will test it out further tomorrow.

[ryan]

@Jens Martsch - dotnetic Heh, no problem, that happens here regularly too. :) Let's get back to your first video—I'm trying to figure out how to duplicate this one. I think you could be on to something here because many Fieldtype methods require a Page object, and there is no Page object associated with each image. As a result, we use a fake Page without an ID, and I'm guessing this is the source of the error you are seeing, but I can't figure out how to duplicate the scenario here. Here's what I've done to attempt to duplicate: 

I've started with a new instance of the "Regular" site profile, added a field-images template, and added fields to it.  Logged in as superuser, I edited the /about/ page, uploaded an image to the image fields, and populated all my custom fields with text, and saved. 

I created a new role named "editor" and checked the box so that it has page-edit permission to "home" (which inherits through the tree). The user doesn't have any other permissions. I created a new user with this role, logged in with it, and edited the /about/ page and clicked to open the images field. I can see all the field text, and modify and save it as well, and changes are retained. So I'm not sure what to try next in terms of duplicating the issue, so I'll ask a few questions;

1. Do you have any field-level access control involved here on your images field, or on any of the fields defined on your field-images template? 
2. Did you enable access control on your field-images template? (it should be disabled)
3. Do you have any modules installed that add access control hooks or modify the way access control works?
4. Do you have any optional core permissions installed? (like page-edit-created, page-publish, page-edit-images)?
5. Any other factors you can think of?

Thanks! 

[Klenkes]

Quote

1. Do you have any field-level access control involved here on your images field, or on any of the fields defined on your field-images template? 

No.

1. Did you enable access control on your field-images template? (it should be disabled)

No.

1. Do you have any modules installed that add access control hooks or modify the way access control works?

No.

1. Do you have any optional core permissions installed? (like page-edit-created, page-publish, page-edit-images)?

db-backup, form-builder, form-builder-add

1. Any other factors you can think of?

See below.

I have a pretty basic testsite(intermediate profile) with no additional modules and no hooks whatsoever.
But... it's a multilingual site, German as default plus English.

Now:
If I set my profile to english my german fields are empty. English field content is shown.
When I edit the content and save, the content is saved(I see it on frontend AND database), but on reload of the page(after the save action) the german content is gone. Well, not really gone, but not shown...

Then I set the profile language to German(default language) everything works as it should, and all field are shown and saved.

This happens to me as superuser.

Strange...

[Klenkes]

I just recreated it with a new installation.

1. Install multilanguage profile
2. Create the imagefield, add to template home
3. Create a template for the image field, add field summary
4. Go to home, add an image, fill in title and summary
5. Switch your profile to german language or finnish, and edit home again
6. All entries show up, except default language!
7. Only additional fields are affected. Standard image description works.

You can do all this as superuser.

To clarify again: What you type in an as empty shown field is saved to the database! But the field is shown as empty, as is the language tab.

[dotnetic]

I hope I can report back soon, but I am still very busy. Multilanguage is also active in my system. Beside that I also use different hooks to restrict edit and view access, so this might be another culprit.

[eelkenet]

On 10/17/2019 at 9:41 AM, Klenkes said:

I just recreated it with a new installation.

1. Install multilanguage profile
2. Create the imagefield, add to template home
3. Create a template for the image field, add field summary
4. Go to home, add an image, fill in title and summary
5. Switch your profile to german language or finnish, and edit home again
6. All entries show up, except default language!
7. Only additional fields are affected. Standard image description works.

I can confirm, this issue also appears on my installation. It's easy to miss unless you change your own profile language.  

Besides, I found a another minor bug: switching all multi-language input fields at once (double click on language-tabs) closes the image field.  
Reproduction is easy: With an image field in the regular grid mode and an image opened: double click any language-tab inside the custom fields template (to change all fields to that language). This switches languages, but then immediately also closes the image field. In this case the javascript event should not propagate any further. 

 

[ryan]

@Klenkes @eelkenet @Jens Martsch - dotnetic Thanks, I was able to duplicate and fix the issues mentioned above. Please let me know if you observe any other issues. 

[d'Hinnisdaël]

@ryan Do the custom file fields currently support FieldtypeOptions? I created it in my ›field-image‹ template, but it isn't shown in the image editor UI (no markup created). Checkboxes, text fields, page selects all seem to work fine. Your screenshot in the introduction blog post looks like it's using FieldtypeOptions fieldtype with radio buttons. Or is that a Page field?

[Macrura]

For some reason I'm running into an issue here with trying to add custom fields to an images field.

ProcessWire\PageFinderSyntaxException

Field does not exist: author_images_....

[dragan]

@Macrura Are you doing a search of some sort? i.e. using a selector? A field name like author_images_randomgibberishstring sure looks strange. Did you name it like that?

In "regular" image fields I found the new feature works just fine, also with multi-language. Maybe you are using an image field inside repeaters?

[Macrura]

54 minutes ago, dragan said:

Are you doing a search of some sort? i.e. using a selector? A field name like author_images_randomgibberishstring sure looks strange. Did you name it like that?

No search,

no selector;

No - the system makes up field names like that which comprise the custom field, the image field, and the id of the asset. [custom_field]_[file/images_field]_fileID. You can inspect any files or images field where you have custom fields and you'll see the same thing.

54 minutes ago, dragan said:

Maybe you are using an image field inside repeaters?

No, no repeaters.

[dragan]

@Macrura Did you create a template (without file) according to Ryan's "how to" (step 3) ?

Quote

Create a new Template (Setup > Templates > Add New). In “Create a new template without a file” input, type in “field-files”, replacing the word “files” with the name of your field (i.e. “field-images”, “field-photos”, “field-downloads”, etc.). Click the “Add Templates” button to save.

Perhaps you have to only replace _ with - in your template name. From what I gathered, it should be a - character, not _.

[Macrura]

2 minutes ago, dragan said:

Perhaps you have to only replace _ with - in your template name. From what I gathered, it should be a - character, not _.

thanks - no, the template itself is named correctly, field-images; else the system wouldn't pick it up as a files field definition template... The output field naming (what is being generated in the edit form) is handled by the system..

[Macrura]

I have been able to track down the issue, the cause of the crash was my own module – TextInputAwesomeplete which was not compatible with the new custom fields on images feature. I have pushed a fix, but i wonder about the core, in terms of it being able to be resilient against a pagefinder query that incorporates one of the 'virtual' fields.

https://github.com/processwire/processwire-issues/issues/1104

[Jan Romero]

Tbh, I find this whole “virtual field” business somewhat unfortunate… The announcement of custom image fields filled me with joy, and I thought the idea of using templates seemed pretty ingenious (although I don’t like how it introduces magic strings into template names, and generally restricts their naming, and doesn’t allow multiple image fields to share a template. Feels icky to me. Why not have a template selector in the field settings?). However, I was disappointed to find that values are just serialized and dumped into the image-field table. Seems like this data is treated as some kind of second-class citizen. If the custom fields were stored in their own database columns, as suggested by using templates and fields, it would have been a trivial INSERT to migrate from the ImageExtra module. Now I needed to use the PW API to move values from one field to the next, which involves all kinds of voodoo behind the scenes.

Wouldn’t it be much less work to just store a page reference with each image and have the custom image fields stored in their respective field-tables? Surely that way it would be easier to make everything play nicely with selectors and everything?

Of course, I have to admit I don’t have a lot of MySQL experience. Maybe there are easy and performant and reliable ways to query serialized fields like this and I just need to read up a little ?