Macrura

This is a status update regarding the 4 modules: 1) JquerySelectize This module is not be required by any of the modules below, for PW versions > 3.0.66. Latest version also allows the module css/js to be loaded instead of the core css/js - mostly for testing/debug. 2) InputfieldSelectize (and InputfieldSelectizeMultiple) Everything seems to be working fine. The dependency on the JquerySelectize is removed for versions > 3.0.66, and the module inits the core library when in use. If JquerySelectize module is present/installed, then it will hand off the loading of the assets to the module, where you can then choose where to load from. 3) SelectizeImageTags UPDATE - latest version should work now - if you use this module with any PW version > 3.0.66, please update to the latest version. 4) SelectizeTemplateFields This works fine with the core selectize. The dependency on the jQuery module is removed for versions > 3.0.66.

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: Tags disabled User enters tags by text input User selects from list of predefined tags 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: 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 ?)

@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...

Finally got a chance to try it and this module is great, and will solve innumerable content management conundrums.. Here's my first use, on a quotes rotator section: Field Config: var colheaders = ['Author', 'Publication', 'Quote']; hot.updateSettings({ colHeaders: colheaders, minCols: colheaders.length, maxCols: colheaders.length, rowHeaders: false, minRows: 1, minSpareRows: 1, maxRows: 5, width: 900, contextMenu: true, autoWrapRow: true, autoWrapCol: true, colWidths: [200,200,500], }); edit screen: output:

I think it will be important for VPS to support image fields that are multiple; i don't quite get why there is a requirement that the image field must be a single image. Here is one scenario where that restriction fails: - You have YouTube & Vimeo Thumbnail grabber, getting poster image for a video. This module requires that the image is NOT single (must support multiple images). - You want to setup a VPS field to choose videos, however it won't work because the VPS requires the thumbnail field to be single image. I have a lot of other situations where I was hoping/assuming the module would use the first image when image field is multi, so this could be a major problem for how i was planning on using it. If you can modify the module to just go ahead and use the first image for these cases, that would solve this. Another important feature will be to allow editing of the item by clicking on it – i didn't see an option for that, let me know if that is possible to enable. Next, when in lister mode, there is still an edit button on the lister which could really confuse clients and also create a crazy modal view (since the button include the whole admin theme and not just the edit screen... Next - how do you preconfigure the columns for the lister, or can you specify to use a lister pro that is already configured? Somewhat confused about that. I need to have specific columns for the lister view, that will apply to all users. Thanks!

Hi - i'm not sure if @owzim is around, i don't have a multilanguage testing environment at the moment so might take a while to fix this; looks like a css issue, and possibly not that hard to fix..

The JquerySelectize module, that all of the other Selectize family modules require, has been updated (to version 1.0.1) as follows: 1) Checks to see if the core version is 3.0.67 or higher (version at which selectize was added to core), and if so, will load the core files, and not this module's files. Using the ProcessWire core versions of selectize.js improves the user experience, because of the adjustments that Ryan made to the plugin, which relates to hitting enter key after typing a tag (which would by default submit the form). 2) In addition to loading the CSS & JS from the core, when working in versions 3.0.67 or higher, the module still provides a skin selector. While most users will probably stick to the core non-skinned version of Selectize, the module provides this option to choose a different skin. There are some scenarios where choosing the default or bootstrap skins for selectize can be preferable, as they may be higher contrast or more pronounced with color usage, and can help in some ways with accessibility for users with any type of vision impairment. Currently the update/behavior only applies to Selectize modules family that require and use the JquerySelectize module, so if you are using core image tags and have this module installed, it won't change the skin; However there is a plan to try and hook into the image field rendering and enable this module to add the custom selected skin to the css files.

i have one type of button that submits via ajax so does all of the processing without opening a new window; some of my more primitive versions just open a new window to run the action...

What i did was to make the Page ID field editable, that was the only way to test the module with a dummy events feed and then switch it out to a different page; the clear module cache select item is not working for some reason... in line 66 of the FacebookEventsConfig.php you can comment out this: $field->collapsed = Inputfield::collapsedNoLocked; ... ... I made some other changes to the module to allow the users to configure the since date, and until date; Once that's all stable i'll hopefully do a pull request on github for the extended features; and if i can figure out how to make it update the ID of the page if the cache is set to expire now, i'll post back here..

module alert!

so if you have your html text in a $body variable, you can then do something like this: <?php $base_url = 'https://www.example.com'; $absoluteFiles = $base_url . '/site/assets/files/'; $alignLeft = 'style="float:left;margin-right:10px;"'; $placeholders = array( 'class="align_left"', '/site/assets/files/', ); $replacements = array( $alignLeft, $absoluteFiles, ); $body = str_replace($placeholders, $replacements, $body);

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.

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...

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.

looking forward to using this module... thanks for building it!

fyi MySQL >= 5.7.8 supports searching inside JSON

cheers and thanks again for helping! ... just merged

Hi @Robin S - many thanks for working on this! The only issue i see is that i know i have this running on a few 2.7.3 sites – perhaps there should be a version check within the module and then use different method to support legacy?

yeah, to achieve what i was referring to above, i had a hook on the save of the main page, which iterated through all of the items in the pagetable where the field was blank, and set that value... Has anyone come up with a reliable way to get the ID of the page that contains the page table field, either through hook, database query, or session vars? would be very helpful to know if this has been solved - maybe @Soma could you post an example of how to set the id of the page in the session; my issue with this is i have a page in a page table, which then has another page table in it, so the system is having trouble with any get var because it ends up being the root/bottom page, not the 2nd level up modal which is the page id i need...

nice!

i mainly use the options fieldtype for non relational type selects with huge numbers of options, such as countries, cities, states, and such where i just don't want those things showing up as pages..

if there is anything i can change or fix in the PrevNextTabs module, let me know

i think this has to be moved/merged with blog thread https://processwire.com/talk/topic/7403-module-blog/ though i'm not sure exactly how to do that..

cool, ok thanks – will accept/merge asap.

Wow didn't know that; i had avoided repeater matrix in this particular scenario because the pages i use for the sections have a lot of fields, and use a 2-column layout as well; Also, i like to be able to direct edit the sections from the page tree once in a while; but certainly for simpler applications, the repeater matrix sounds awesome and i'll have to give it a go soon... Another reason why the Micro Contexts idea will still be useful is for templates that are not in a repeatable context; But you have brought up the issue of the interface, so perhaps i need to have a process module that can show the various related contexts on 1 screen...