ryan

PW 3.0.67: Upgrades to file/image tags

31 posts in this topic

This week's version includes some helpful UI updates to the tags feature available in our File and Image fields, which we'll be taking a closer look at in this post. Like many versions, this also includes some other updates consistent with submitted GitHub issue reports. Read on for all the details…

https://processwire.com/blog/posts/processwire-3.0.67-upgraded-file-and-image-tags/

 

13 people like this

Share this post


Link to post
Share on other sites

just upgradet to the newest dev version and tested it. Loving it, Ryan! 
That's what is best about processwire; you are free like a bird and have countless possibilities to realise your ideas with core functions.

3 people like this

Share this post


Link to post
Share on other sites

Love it. I use file and image tagging extensively and it's one of the few PW methods which trips clients up. I was just wondering during the week if it was possible to have a tag selector based on something a bit more dynamic. Thanks :-)

Share this post


Link to post
Share on other sites

Wow, i'm having Déjà vu...

http://modules.processwire.com/modules/selectize-image-tags/

Glad this is in the core now though; personally i couldn't have done without my module version for the past year (used on dozens of sites).

Wondering if i can now remove the dependency for the jQuerySelectize module and load the core selectize js in the module init.

Questions would be:

1) does the new integration allow you to select the Selectize skin?
2) will the core selectize interfere in case you upgrade and have image fields set to use the module selectize image tags
3) can the limit of what tags can be used be set on the field settings, and can those tags preferences be over-ridden per template, like the module.

7 people like this

Share this post


Link to post
Share on other sites

could anybody of you guys using image tags please give me an example when and what for you use it? :) i've never used image tags in the past 3 years and would like to make sure if i was missing something or if i just had no use for it :D thanks!

Share this post


Link to post
Share on other sites

Eg upload a company logo to an image field that holds many images. Then add the tag "logo", and use it as the main brand logo. Then perhaps upload another one with tag "footer_logo", and so on.

Or mark files for different languages as Ryan recommended lately in a blog post. Or mark images to skip, eg for a gallery. I guess you got the idea now.

3 people like this

Share this post


Link to post
Share on other sites

thanks, got it :) have to start using it. i understood the multilanguage part but never needed it so far. but it seems that i will use more tags and less imagesfields in the future (i used to create single fields for what you describe) :D thanks!

Share this post


Link to post
Share on other sites

Is it just me or what - I can't add tags if page is not saved first?

Share this post


Link to post
Share on other sites

it definitely helps with managing images in situations where you have a single images field on a page, and want to use some of those image in the RTE, while still specifying one to be used as the 'featured image', which might appear above a blog post. Using a tag like gallery on multiple images could then be used to output a carousel as that featured image, instead of a single image...

3 people like this

Share this post


Link to post
Share on other sites

@Macrura looks like a could have saved a lot of time here if I'd found your module first, sounds like we were after the same thing, except that you were well ahead of the curve on this. Right down to the Selectize library even. I started working on this after the post a couple weeks ago detailing how to handle multi-language with images, and feeling like an idiot for not even checking to see if someone had built this already. 

I ended up modifying the Selectize library because I couldn't get it to work quite how I wanted to for a couple of instances. Like when doing the createFilter, where you only allow certain tags, if you hit enter and the tag wasn't allowed, it would submit the form and save the page, rather than just refusing the tag. There were a couple little things like that I had to tackle, but otherwise it's pretty close to stock. 

To answer your questions, I didn't add support for Selectize skin, and instead modified the default style to be independent of color palette so that it would work equally well regardless of admin theme. I just thought the other theme colors weren't mixing well with our admin themes.

As for interference, there may be. I don't know a good way around it other than to check if Selectize is already in the core, like if(is_dir($config->paths->JqueryUI . 'selectize')) { $modules->JqueryUI->use('selectize'); } else { /* selectize not present */ }. But since your module came first, perhaps a good route would be for the core to detect if your module is present and skip over the built-in tag stuff when it is?

Yes, the tags can be limited in the field settings. No it can't be changed per-template yet, but that's simple, I'll add that.

@matjazp I'm not sure I understand the question? At least, I don't have to save a page before I can add tags, but if you think there's an error let me know steps to reproduce. 

Share this post


Link to post
Share on other sites

@ryan The menu to select predefined tags doesn't show unless the page is saved.

After a file is uploaded there's an error in the console:

log.png.993edd60c8fe89993bde05fb6f9dd636.png

Image field with "User selects from list of predefined tags" option selected.

Share this post


Link to post
Share on other sites
2 hours ago, ryan said:

As for interference, there may be. I don't know a good way around it other than to check if Selectize is already in the core, like if(is_dir($config->paths->JqueryUI . 'selectize')) { $modules->JqueryUI->use('selectize'); } else { /* selectize not present */ }. But since your module came first, perhaps a good route would be for the core to detect if your module is present and skip over the built-in tag stuff when it is?

There could be a lot of people using the module version for image tags; I will revise the module code to check the core version or the is_dir and then load from core – it does seem that your tweaks are going to be essential for this, as that behavior of it submitting is definitely a problem, that i hadn't noticed (i always assumed that users would click and select, but now i see that they can type stuff in and try and hit enter..)

Another issue is that there is the other module that uses selectize, namely the InputFieldSelectize (and the multiple version) which are page reference fields, and those also load the selectize library. I'm pretty sure there are at least a handful of people actively using that fieldtype, so maybe I will also need to use your modified version of the seletize library in the JquerySelectize base module, so that the selectize family of modules will all behave the same way, whether the library is loaded from the core or from the module, and in situations where someone is using InputfieldSelectize, but not image tags.

if the core version of the library could include the skins, and in addition, your modified skin, then the module version could allow skin to be chosen (if it is installed), but if not installed, then the core version uses the default skin.

In the module config for the JquerySelectize, besides offering the option of changing the skin (existing and new PW admin theme neutral version), that could be a place to specify which selectize library to load (core or module), to allow users with an existing setup to gracefully test and transition to the core version. Once they have tested their setup using the core version as specified in the module's config, they could choose to keep the module installed (for the extended skin options) or uninstall it and use the default skin.

5 people like this

Share this post


Link to post
Share on other sites
16 hours ago, ryan said:

@matjazp I'm not sure I understand the question? At least, I don't have to save a page before I can add tags, but if you think there's an error let me know steps to reproduce.

@ryan I have to save the page before I can enter tags using selectize. There is also js error, as @fbg13 mentioned. It looks like some html is missing on newly uploaded image, like 

<div class="selectize-control InputfieldFileTagsSelect multi plugin-remove_button plugin-drag_drop">...</div>

 

Share this post


Link to post
Share on other sites

@ryan Thanks for the fix! I find the active tags background color to light, not enough contrast to see which tag is active (.selectize-dropdown .active{background-color: #d7e2e6;)

Share this post


Link to post
Share on other sites

@ryan

i seem to be running into an issue where i'm not seeing the remove button anymore, this applies to the inputfield selectize, where you have a multi page select; the remove button is needed to remove items from the mutli page select, but there seems to be something in the core version that is different and possibly not loading that remove button. Let me know if i need to change something with the inputfield in terms of loading the remove_button plugin, when working with the core version of selectize...

OK figured it out, sort of - if you have a link in an item, then the remove button doesn't appear – not sure when this behavior changed and may be a plugin related issue; a lot of times i put in a link to edit the page using something like this:
 

    '<a class="pw-modal pw-modal-medium" href="' + escape(item.edit_src) +
    '">Edit <span class="ui-icon ui-icon-extlink"></span></a></div>' +

but with that inside the item markup, the remove button disappears... will troubleshoot more and post back; not sure how many users of the inputfield are including page edit links, so this may not have come up as an issue yet for any users of this inputfield...

Share this post


Link to post
Share on other sites

The new core implementation of image tags seems to definitely not be compatible with the module, at least from my initial testing;

1)

the first problem is that the core image tags do now allow for key/value pairs, where for example you can have a tag be something that is used by the api, like 'gallery' and the visible tag value be something easier to understand, like "Gallery: use this to group images into a gallery". I was using key/value tags a lot on some sites and now won't be able to upgrade to latest version until something is resolved.

Forget this, i have worked on the module and it will just prevent the core js function from initializing the field and turn that init over to the module, when this module is in use.

2)

the 2nd problem is that the core implementation still does not allow for different tags to be specified for context, and this is going to be critical;
if you are using 1 images field across the site, but need to have different selectable tags based on which template that images field is on, then the tagging feature needs to be context enabled per template, as @ryan mentioned he would implement above.

This would still be nice/useful.

3)

in the event that the core implementation is not going to support both template context for selectable tags, as well as key/value for tags, then it would be great to allow my module to continue working for image fields. In order for that to happen, then there needs to be another option for the use Tags, here are the current options:

  1. Tags disabled
  2. User enters tags by text input
  3. User selects from list of predefined tags
  4. User selects from list of predefined tags + can input their own

Here are the current identified problems with the existing options:

1. Tags disabled: If tags are disabled, it seems to clear some values from the database, even without saving the pages that the field is on; in my case i lost an entire website's worth of tags on images because i assumed that if i disabled tags here, that i could re-enable them and that the tags would still be there. This wrong assumption led to some hours of re-tagging an entire site worth of images.

2. User enters tags by text input : This 2nd option should probably read "User enters tags by text input (using Selectize)"

Another option should be added below this:

2a. User enters tags by text input (legacy, free text field)

This option would leave the inputfield free to be initialized by the module instead of the core.

Forget it, this is all sorted now.

--------

 

On a separate topic, Z-index issues remain a problem:

5989cb06ef138_Edit_Page__Jane_Eyre__louiskarchin_com.jpg.f30463e409c14c16b0afef05cd8725f5.jpg

these CSS rules fix the z-index problem:
 

.InputfieldImageEdit__name {
    z-index: 2 !important;
}

.InputfieldImageEditAll .gridImage .ImageData {
    position: static !important;
}

Also, there is still an unresolved issue with something in the JS causing a conflict when an anchor tag is added to an option (which is frequently used on the InputfieldSelectize modules). Fixed now (somehow ?)

3 people like this

Share this post


Link to post
Share on other sites

I do not want to grumble at all, and I hope my positive criticism will not be misunderstood but I would like to point out that ProcessWire's development road is a bit ad hoc these days.

Do not get me wrong, I like it when Ryan needs some features and surprises us with stuffing them into the core, but this method of pushing the system further is still missing a crucial step: discussing the features to be implemented/refactored by the developer community.

Also, we have a long list of feature requests but no one knows how and when they will make their way into the system if ever. They just seem to be forgotten. Only one example: Changelog support with 890 views and 11 likes possibly hits the 30% threshold set by Ryan but it is still waiting to be picked up. And there are many others as well, also at Github.

7 people like this

Share this post


Link to post
Share on other sites
3 hours ago, szabesz said:

Also, we have a long list of feature requests but no one knows how and when they will make their way into the system if ever.

I think we need something like UserVoice for PW feature requests, so Ryan and other core developers can gauge the level of support for individual requests and prioritise accordingly.

It would actually be good to have the same for PW issues, so we can get an indication of which issues are particularly problematic to the largest number of users. :)

3 people like this

Share this post


Link to post
Share on other sites
8 hours ago, Robin S said:

prioritise accordingly

I 100% agree that no one needs endless discussions about issues to be solved, what we need is priority and the way to indicate importance. Using the right tool could probably solve this issue.

1 person likes this

Share this post


Link to post
Share on other sites
1 hour ago, szabesz said:

I 100% agree that no one needs endless discussions about issues to be solved, what we need is priority and the way to indicate importance. Using the right tool could probably solve this issue.

I also agree, but I'm not sure such a tool would be helpful since Ryan has his own way of doing things. What we need is more or less visible by looking at open issues, pull requests and feature requests.

1 person likes this

Share this post


Link to post
Share on other sites
32 minutes ago, matjazp said:

pull requests and feature requests.

We already have those, haven't we? How do they help in prioritizing issues? Poll like features attached to issues with some overall statistics could help to see the big picture. Skimming through fragmented bits of info makes things harder that they should be.

Share this post


Link to post
Share on other sites

Is anyone seeing a problem with the new image tags, where all of the image or file tags disappear when you upload a new item?

Its happening to me on 3.0.70 on file and image fields.

Thankfully the tags do not get removed from the items, but they all become invisible when you add an image or file. I'm guessing the core InputfieldFile is reloading the field after upload but the selectized fields are maybe not set to reinit on reloaded ?

Here is a GIF of the behavior when using core selectize image tags:

598c41da40fd1_tagsproblem.gif.037c4912f9b0fdbe7fa2c3269d5b081d.gif

 

Here is it working correctly, using the module init of the field (same core selectize version)

598c4225389ff_tagsmod.gif.2736e8aaff091e96d0d327360c8b8297.gif

 

1 person likes this

Share this post


Link to post
Share on other sites

why webp still is a invalid file extension?? No make sense for me if I only need to use the url to the file in my pages, I'm not processing the image data.. only print the path

Share this post


Link to post
Share on other sites
On 10. 8. 2017 at 5:12 AM, Macrura said:

Is anyone seeing a problem with the new image tags, where all of the image or file tags disappear when you upload a new item?

Happening to me on PW 3.0.71 

Share this post


Link to post
Share on other sites
On 8/8/2017 at 10:39 AM, Macrura said:

these CSS rules fix the z-index problem:


.InputfieldImageEdit__name {
    z-index: 2 !important;
}

.InputfieldImageEditAll .gridImage .ImageData {
    position: static !important;
}

 

 

@matjazp you can add those to your AdminCustomFiles, or use the SelectizeImageTags module which has the fix built in; not sure what other ramifications of these CSS overrides are, but so far they work and i haven't seen any issues, but they do override core CSS styling on the image field.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.