Recently Updated Topics

@bernhard I wasn't able to provide a more robust response above but I wanted to mention that my concept wasn't an impulsive decision. I think my language in the confirmation popup should be changed. The "clear all" feature is a shortcut to clear all content in all languages including the default language so that it has one purpose. One of the things that I first had to consider was how often the feature gets used. Fluency has been available for over 5 years and this feature absolutely has great value but hasn't been mentioned before. I haven't heard about users/devs expressing a need to clear all content from multilanguage fields, and the general practice has been in my experience that if content changes then it would involve entering new content and re-translating. I thought about weighing how often the feature would be used compared to translation and it seemed like much less often, but I didn't have experience to go on. I also wondered if this was a feature that was use most during the initial build and population of content vs. ongoing content management. I think that was another area where the use of the feature may change over time as far as how often it's used, but again I haven't had the need so my understanding may be limited there. I'm not against the concept of a always-visible button or icon. Throughout the admin UI the trash icon is, as far as I can tell, mainly implemented for block, group, or object deletion rather than field contents. This is where the use of the trash icon without a label to explain the difference between what it means when used specifically for a field could be confusing because it does break from what it signifies elsewhere. The position of the translation action menu to the right as a clickable option felt natural with destructive actions located elsewhere. Placing it under a dedicated language icon menu seemed like it would strongly associate the action exclusively with multilanguage field features. Each field can have translation disabled, so there would have to be a decision whether to include just a trash icon even if there is no translation enabled for consistency when working with multilanguage fields. I think this could be a great convenience enhancement even if it steps outside of Fluency's current purpose and may be even be necessary for consistency. This may present another challenge because only multilanguage fields would provide the ability to delete content from the primary field that is visible where all other fields that only have primary content would need to manually be deleted. It's a step that may push a little further into ProcessWire's core behavior because some fields enable you to delete content for the default language alone, but other fields that are not multi-lingual still require a select-all-then-delete action by the user. If the trash icon is not present on all fields, would it seem like an oversight? Another thing that comes to mind is whether a multilanguage field with translation disabled were next to a single language field. On the left you can delete the primary content without deleting any other language, but on the right you can't delete the primary content with one click. The tabs hint that it's related to language fields, but non-language fields aren't afforded the same convenience even though they are visually similar to the end user. The intention is to have the clear all button clear everything in one action, so if the user is aware of the feature then they wouldn't clear any text to begin with. I think the language I used in my original "confirm" example may not have been as descriptive as it should be. It's an all-or-nothing action. The wording you used: "Are you sure you want to clear content in all languages for this field?" is much better and communicates clearly. So my approach was placing the option under an action menu since it felt natural to group secondary behaviors. The button that opens the translator is secondary and the ability to delete content in all languages is secondary compared to the primary feature of translation. I like the ideas and want to take the best approach, and I'm not against any specific implementation. Thinking through this though when you originally mentioned stepping into "core" behavior may be more impactful than it seemed when putting all different types of fields into the mix.

Hi @bramwolf that's great! Great you found the reason for the issue. The multisite module is a dinosaur and has not seen any updates in 7 years. Of course in the ProcessWire universe this does not have to mean anything and soma for sure knew what he was doing, but I tried the module several times and always got into trouble somewhere. Rewriting page paths is a huge change and 3rd party modules (like RockCommerce) might need to account for such situations (or the other way round). So to be clear hear, I'm not going to even try to officially support the usage of RockCommerce together with any unofficial multisite module. I have written my own RockMultisite module and I'll likely never share it with the public because there are too many possible pitfalls. Having said that, of course I do try to help you and if there is anything I can do to make it work for you without breaking anything for anybody else I'm happy to do that! But unfortunately I don't understand what you are trying to say here: --- Thx for that question. I was totally thinking that I mentioned that in the video, but turns out that I had the RockCalendar module in my mind. See this section of the showcase video: https://youtu.be/40h6I4i8JKs?si=rTlUzI95f8tH4dNr&t=254 This is exactly the same case/reason for RockCommerce and this shows why it's a separate module. Because I need the features/UI for multiple other modules. It seems that this information was missing for RockCommerce and I'm sorry for that. I updated the docs here: https://www.baumrock.com/en/processwire/modules/rockcommerce/docs/product-variations/ If you have any further questions let me know.

Thank you @teppo this is so helpful. I am trying your hook code above, but it says undefined method returnResultsJSON() after placing it in /site/ready.php Strange. I see that the method is referenced at the top @method in the module code. What am I not understanding ? Edit: I ended up getting this to work by creating /site/templates/search.php with the following code: <?php namespace ProcessWire; if ($config->ajax) { // AJAX request, send JSON header, output JSON and exit header('Content-Type: application/json; charset=utf-8'); echo $modules->get('SearchEngine')->renderResultsJSON(); exit; } Crucially, I forgot to create a new template 'search' and a new page using this template in the PW Admin Panel, (the page is titled 'Search', and set as a Hidden Page). After that, I had to modify my markup to use the search page endpoint as the url. header.latte (where the search bar markup lives), passing options to the /search/ endpoint url <div class="uk-visible@m"> {var $searchengine = $modules->get('SearchEngine')} {* Pass the form_action parameter to point to your search.php file *} {var $formOptions = ['form_action' => $config->urls->root . 'search/']} {$searchengine->renderForm($formOptions)|noescape} {$searchengine->renderResults()|noescape} </div> The Javascript @teppo provided, with a modified fetch query: const findResults = () => { window.clearTimeout(searchTimeout) searchTimeout = window.setTimeout(() => { if (searchResults) { searchResults.setAttribute('hidden', 'true') } if (searchInput.value.length > 2) { if (searchCache[searchInput.value]) { renderResults(searchForm, searchCache[searchInput.value]) return } if (searchInput.hasAttribute('data-request')) { return } searchInput.setAttribute('data-request', 'true') searchInput.setAttribute('disabled', 'true') const searchParams = new URLSearchParams() searchParams.append('q', searchInput.value) fetch(`${pwConfig.rootUrl}search/?${searchParams}`, { headers: { // set the request header to indicate to ProcessWire that this is an AJAX request; this // way we can check $config->ajax in the template file and return JSON instead of HTML // by calling $modules->get('SearchEngine')->renderResultsJSON() 'X-Requested-With': 'XMLHttpRequest', }, }) .then((response) => { if (!response.ok) { throw new Error('Network response was not ok') } console.log(response); return response.json() }) .then((data) => { searchCache[searchInput.value] = data renderResults(searchForm, data) searchInput.removeAttribute('data-request') searchInput.removeAttribute('disabled') searchInput.focus() }) .catch((error) => { console.error('Error fetching search results:', error) searchInput.removeAttribute('data-request') searchInput.removeAttribute('disabled') searchInput.focus() }) } }, 300) } and an additional <script> tag in _main.php to allow the above javascript to reference the ProcessWire root properly within my MAMP local dev environment <!-- Create a global object to store ProcessWire paths for ajax search hook --> <script> var pwConfig = { rootUrl: '<?= $config->urls->root ?>' }; </script> Maybe this is not the most elegant way to do this, but it seems to be working nicely now. I spent too many hours trying other ways. Maybe someone could point out redundancies or a better methodology. Sharing this here in case anyone else wants to add some nice AJAX functionality to @teppo's fantastic module. Thanks!

I'm currently having this issue and fixed it with this hook: /** * CSS: Hide the empty height space of inputfield columns when they stacked (mobile / tablet) on ProcessPageEdit * */ $wire->addHookAfter('ProcessPageEdit::execute', function(HookEvent $event) { $event->return .= " <style> @media only screen and (max-width: 767px) { .maxColHeightSpacer { display: none; } } </style>"; });

will there be AVIF support?

I'm adding a header action with something similar to the following: Inputfields.addHeaderAction('title', { label: 'Some custom actions', icon: 'fa-question', menuItems: [ { label: 'Option 1', href: 'https://somedomain.ddev.site/admin/page-to-show/', modal: true, active: true, callback: null, }, { label: 'Option 2', callback: function() { ProcessWire.alert('Shows option 2'); }, active: true, }, { label: 'Option 3', callback: function() { ProcessWire.alert('Shows option 3'); }, active: true, }, ] }); When there is a combination of types of actions then the options that execute a callback will trigger the option that executes a href/modal. When clicking the option that opens a modal, the other options are not triggered. Example that opens the "Logs" page in a modal. Clicking "Option 2" executes both the callback and opens the modal in "Option 1": The same occurs if "Option 3" is clicked. I'm trying to figure out if this is something I'm doing wrong or if there's a bug when mixing option types. I was able to create a workaround by adapting this code by @bernhard that uses a callback to programmatically open a modal: Inputfields.addHeaderAction('title', { label: 'Some custom actions', icon: 'fa-question', menuItems: [ { label: 'Option 1', active: true, callback: function() { const link = document.createElement("a"); const $link = $(link); $link.attr('href', 'https://moduledev.ddev.site/admin/setup/logs/'); $link.addClass('pw-modal'); $link.on('click', pwModalOpenEvent); $link.on('pw-modal-closed', () => $link.remove()); $link.click(); }, }, { label: 'Option 2', callback: function() { ProcessWire.alert('Shows option 2'); }, active: true, }, { label: 'Option 3', callback: function() { ProcessWire.alert('Shows option 3'); }, active: true, }, ] }); This works but doesn't use the native API. Anyone have any insights that could help? Many thanks!

Same thing here, though so far only seen it on one site. Not sure if it was an isolated issue or if it just hasn't come up yet on other sites 🙂

@bernhard I was working on some blocks in RPB and noticed that there were some edge cases where changes weren't being detected by RPB. I ran into this with the trash icon on RepeaterMatrix items. Clicking it checks a hidden checkbox programmatically and doesn't emit a change event, so it's pretty much invisible to everything else that isn't RepeaterMatrix code. I added this mutation observer to InputfieldRockPageBuilder.js to watch for elements that have had the 'InputfieldStateChanged' class added. // trigger changed event when InputfieldStateChanged is added to elements $(document).on('ready', function () { const rpbItemsObserver = new MutationObserver(mutations => { mutations.forEach(mutation => { if (mutation.target.classList.contains('InputfieldStateChanged')) { RockPageBuilder.changed(mutation); } }); }); $('.rpb-items').each(function (_, rpbItem) { rpbItemsObserver.observe(rpbItem, { childList: true, subtree: true, attributes: true, attributeFilter: ['class'] }); }); }); In my testing this took care of some edge cases where changes aren't visible to RPB. Could be helpful for handling other sneaky inputs as well 👍

This.

@bernhard Absolutely no problem! I do really appreciate all the work you do already. I did try building my own module to do the same kind of thing ... but it just wasn't as good as yours 🙂

Nice, thx for the explanation! Sounds like a cool project!

Thank you Richard. I have the last version of FieldtypePDF with PHP8.3. I was able to correct this problem as I deleted the data in the FieldtypePDF row in the modules table in Mariadb. {"-dups":["\/site\/modules\/ProcesswireFieldtypepdf\/FieldtypePDF.module.php","\/site\/modules\/ProcessWire-FieldtypePDF\/FieldtypePDF.module.php","\/site\/modules\/FieldtypePDF\/FieldtypePDF.module"],"-dups-use":"\/site\/modules\/FieldtypePDF\/FieldtypePDF.module"}

Honestly probably not that obvious so no worries at all.

Thanks for the links, @Robin S. That was very useful!

@tpr thanks for the module! Just a heads-up for anyone looking to use this module with the latest Nette Tester. I’ve updated the tester version from v2.0.2 to v2.5.4 and fixed a few minor issues caused by changes in Tester. You can find the updated fork here: https://github.com/lemachinarbo/ProcessNetteTester Update now is part of the module! https://github.com/rolandtoth/ProcessNetteTester Let me know if I broke something, but it seems to be working (for me... haha).

You can put it in the CSS code field on the module settings like you did or load it inside a CSS file, both is fine. See this example and comments for clarification: /* this overwrites the default for all items */ .pg .pg-item { grid-row-start: auto; } /* this is only affecting new items, e.g. size can still be changed later by resizing items, if you want to set a default size it's better to use this class */ .pg .pg-item-added { grid-column-end: span 3; /* let new grid items span 3 columns */ grid-row-start: auto; /* you can also change the placement here */ }

Nice work, I appreciate it.

oh so simple, duh did a quick test and things seems considerably snappier now! Very nice

@MSP01 Thanks - that's an interesting approach, but it's too late for this time - I'd have to rewrite half of the templates. @Robin S That worked. It's still a bit of coding, since in my case it's more then a dozen templates, but it works. Changed the last line to make it a bit easier when working on numerous parent templates: $arr_of_templates = ["parent_1","parent_2","parent_3"]; // and so on if((in_array($page->template, $arr_of_templates)) && ($user->hasRole('editor'))) $event->return = false; Thank you very much

Thanks. No, because the icons are in a column labelled "Actions", with each icon representing an action you can take rather than a status that the PageTable item has. Plus the module has had its conventions for 8 years now and it would be pretty confusing for existing users if the icons suddenly reversed their meanings.

Oh why does this happen? It worries me I might encounter this sometime.

@jploch no!! sorry for the confusion

Hello ProcessWire forum, I am sharing a new PW install developed for artist Laskfar Vortok, which uses the ProFields module, Rockfrontend, RockDevTools, MarkupRSS, and can even display its contents without Javascript enabled (for low-power devices and browsers). It includes a project archive, simple and straightforward project pages, project category pages, and a CV which utilizes a Repeater Matrix for adding and organizing its constituent elements. All of the contents for this page were imported from a legacy WordPress site using a methodology which I describe in detail here & here. Essentially, the contents were ingested from WordPress REST API endpoints (post data, images, tags) routing them to appropriate destination custom fields within PW. A mostly seamless migration, which necessitated some minor manual adjustments and tweaks. Many greetings, and thanks again for the amazing flexibility of ProcessWire.

I completely missed this syntax! I am living in the PHP of the past 😭

Hi Roych, a nice module, well done! Just one suggestion: In your display the seats are looking downwards (the stage is at the bottom). Wouldn't it be more intuitive to make it all upside down? (That's usually the case in seating displays of airline services during the reservation process.) The advantage is a more natural orientation when booking : The seat to the left of yours also appears to the left in the display. Best wishes ottogal