Leaderboard

I oftentimes create a checkbox field called 'test' and assign it to certain templates. I check the box if the page is a test page. These pages may exist on the live site and I don't want to hide or unpublish them, but at the same time, I don't want them to appear in the XML Sitemap. (not part of this tutorial, but I also noindex,nofollow those pages using a meta tag in the head so search engines don't index them) In that case, you can remove them from the WireSitemapXML like this in /site/ready.php: $wire->addHookAfter('WireSitemapXML::allowPage', function(HookEvent $event) { $page = $event->arguments('page'); if($page->hasField('test') && $page->test) $event->return = false; });

I just started thinking about OEmbeds (PW example 1, example 2) and how best to style them so that they appear responsively. Unfortunately, since there are so many various types of embeds, I can't really think of how best to responsively style them in a generalized way, if it's even possible at all. At the moment I'm only using Neue Rituale's fieldtype, if it matters, and thus far only embedding YouTube videos. By default, their embed/render size is quite small. I was able to successfully make them responsive using a little CSS trickery so that it retains its original proportional ratio and fills whatever container space is available to it. I'll likely add in a max-width at some point. However, using a similar technique on an embed that is intended to be tall/thin-width would be unlikely to work out quite as well. Has anyone attempted this feat successfully? For sharing purposes, here is the solution I'm currently using to make the oembed responsive: PW Template: <div class="oembed" style="--aspect-ratio: <?= $page->oembed->width ?>/<?= $page->oembed->height ?>;"> <?= $page->oembed ?> </div> Vanilla CSS (framework agnostic): /* https://css-tricks.com/responsive-iframes/ */ .oembed[style*="--aspect-ratio"] > :first-child { width: 100%; } .oembed[style*="--aspect-ratio"] > img { height: auto; } .oembed[style*="--aspect-ratio"] { position: relative; } .oembed[style*="--aspect-ratio"]::before { content: ""; display: block; padding-bottom: calc(100% / (var(--aspect-ratio))); } .oembed[style*="--aspect-ratio"] > :first-child { position: absolute; top: 0; left: 0; height: 100%; }

Great you solve it. Jut for explanation: if you hook after Pages::save and save the page again within that hook, this will cause an infinite loop as you already have observed. To avoid this you can either use a before hook like you did or take advantage of the the $page->save([options]) by using `$page->save(['noHooks' => true])`

I'm testing with $config->debug="dev" and there are no major issues. Thanks for the update, @ryan I found these js files that might need some updates for the lastest jQuery (deprecations): /wire/templates-admin/scripts/install.js /wire/templates-admin/scripts/inputfields.js (focus) /wire/modules/AdminTheme/AdminThemeDefault/scripts/install.js /wire/modules/AdminTheme/AdminThemeDefault/scripts/main.js /wire/modules/AdminTheme/AdminThemeReno/scripts/main.js /wire/modules/System/SystemNotifications/Notifications.js /wire/modules/Process/ProcessRole/ProcessRole.js /wire/modules/Process/ProcessProfile/ProcessProfile.js /wire/modules/Process/ProcessPageEditLink/ProcessPageEditLink.js /wire/modules/Process/ProcessCommentsManager/ProcessCommentsManager.js /wire/modules/Inputfield/InputfieldDatetime/timepicker/jquery-ui-sliderAccess.js (upgrade to 1.6.3) /wire/modules/Inputfield/InputfieldDatetime/timepicker/jquery-ui-timepicker-addon.js (upgrade to 1.6.3) /wire/modules/Inputfield/InputfieldPageTable/InputfieldPageTable.js /wire/modules/Inputfield/InputfieldSelector/InputfieldSelector.js /wire/modules/Inputfield/InputfieldPageAutocomplete/InputfieldPageAutocomplete.js /wire/modules/Jquery/JqueryWireTabs/JqueryWireTabs.js (eq) /wire/modules/LanguageSupport/LanguageTabs.js /wire/modules/Jquery/JqueryTableSorter/widgets.js /wire/modules/Jquery/JqueryTableSorter/JqueryTableSorter.js (new version 2.31.3 also has issues with deprecated function calls) /wire/modules/AdminTheme/AdminThemeUikit/layout/source/stable/plugins/jquery.layout.buttons.js I would also update ckeditor to v4.21.0 and uikit to v3.16.14. EDIT: Ryan, I tested with this forked version of JqueryTableSorter: https://github.com/DavidAnderson684/tablesorter and there are no deprecations in the lastest version of jQuery. I'm attaching a zip file with the files to be replaced in /wire/modules/Jquery/JqueryTableSorter/ JqueryTableSorter.zip

We've been running pretty much the same jQuery and jQuery UI versions for the last 10 years or more. I haven't really seen much urgency to upgrade because the versions we have work quite well, and I wasn't so enthusiastic about the amount of work and potential headaches the upgrade might entail. Over time there have been been a few security issues found in the jQuery library, which I've always kept an eye on, but they weren't ever things that affected our usage or caused any concern here. The biggest hangup I had was just that upgrading meant also updating a lot of code that uses jQuery, since many of the changes to the library are not compatible with code written for earlier versions. (Newer versions of jQuery have a slightly less convenient API than earlier versions). I place more value on stability than on having new versions of things. But it's always been in the back of my mind that sooner or later it would be nice to get these libraries upgraded for many reasons. After all, newer means better and faster right? Well, not always, but that's been the theme in jQuery at least, that newer versions of the library have some performance benefits over older versions. For awhile now, ProcessWire has been using newer jQuery version only when $config->debug = 'dev'; and I've been testing that out for quite awhile (maybe a year?). This week we upgraded our "main" core jQuery version from 1.8.3 to the last available 1.x release 1.12.4 (4 years newer), which is the one I've been testing. We also upgraded our "dev" jQuery version from 1.12.4 to 3.6.4, which is the newest available version, released by jQuery last month (March 8, 2023). In addition, our jQuery UI "dev" version is now updated to the newest available version, 1.13.2. After awhile, these "dev" versions will become our main versions, but likely not before the next main/master version. While the core seemed to work fine as-is with the newer jQuery (1.12.4), the newest versions of jQuery (3.6.4) and jQuery UI (1.13.2) required quite a few JS file updates to support, and that's primarily what you'll see in the commit log this week. If you'd like to test the newest versions of these libraries in the ProcessWire admin (in a dev environment), edit your /site/config.php file and set: $config->debug = 'dev'; When you do that, it will also load the jQuery migrate library with logging ON. Meaning, the Javascript console will contain messages about things that need to be updated. There's still work to do in the core here, so if you enable 'dev' mode then chances are you'll see some messages about things in the admin too. The "dev" debug mode also makes it use the newest jQuery UI library. Keep an eye out for any visual glitches or any UI things that don't work. For instance, I found that when using the newest jQuery UI version, the image resize/crop tool wasn't working quite right, though I hope to have that figured out soon. Chances are there may be other examples like that, if using the 'dev' debug mode, so please let me know if you come across any. If you are a module author, your module uses jQuery and you want to make sure it's working well with the new main core version (1.12.4) you can also enable jQuery migrate verbose messages in your javascript console by setting the following two in your /site/config.php: $config->debug = true; $config->advanced = true; I've found that updating code for jQuery 3.6.4 seems to be backwards compatible with 1.12.4, so maybe just using the $config->debug = 'dev'; option is a good bet when testing, but I wanted to mention both options are available. I'll be continuing to update our core .js files for 3.6.4 and jQuery UI 1.13.2, and next week will likely update some of our 3rd party jQuery libraries such as the TableSorter library and others. Also, I've not forgotten about pulling InputfieldTinyMCE into the core, that'll likely be in the next version 3.0.216. Thanks for reading and have a great weekend!

Extends Pagefile to use Cloudflare Images, Stream and R2 storage to serve files. https://github.com/nbcommunication/CloudflareAssets The main purpose of this module is to allow ProcessWire to be used in an auto-scaling multi-instance environment. By serving file assets from Cloudflare, it is not necessary to have all file assets copied to all instances and we also get the benefits of serving assets from a CDN. How it works When a Pagefile is added in the admin or via the API, it is uploaded to Cloudflare's R2 storage service. Additionally, if the file is an image, it is uploaded to Cloudflare Images, and if the file is a video it is uploaded to Cloudflare Stream. When a URL for the Pagefile is requested e.g. $pagefile->url(), the appropriate Cloudflare URL is returned. As ProcessWire's admin still requires the file to be available locally, in a multi-instance setup if a file is not available it is downloaded from the 'master' copy in R2. This module is not yet being used in production. There may be changes to how Images work in the coming months as features are still being rolled out to this Cloudflare service. Cheers, Chris

@MarkE - I really do think migration to use imap_open as per my above post would be a better option given the status of the flourish library.

I just pushed a new release adding a new option I needed: the ability to automatically convert relative urls into absolute ones. You can also choose the host to prepend or any query parameters to append. More infos in the settings.

@kongondo wonderful stuff! Works a charm. Cheers as per usual ??

Hi @alexm, That's correct. PadloperProcessRenderOrders renders the GUI. It has lots of hookable render methods. For instance, in demo-2, we hook into PadloperProcessRenderOrders::getSingleViewTableRow (line#29 ) to display the details of the 'customise' text field for the line item. The hookable methods are not yet documented (sorry). Please find them in that file and inject your markup using one of the hooks. Let me know how you get on.

Hi @alexm, That's interesting. I am not seeing the space in my local dev nor in the starter demos. However, I am seeing it on the demo site as you point out. Not sure what's going on there. I know the demo site's Padloper is a bit old but that wouldn't be your case. PHP version differences? Meanwhile, maybe try and remove the space post the fact (str_replace())?

@alexm,Glad you got it sorted! Aren't these conditions resulting in the same thing?

Erm, bit late, but found it here: https://github.com/ryancramerdesign/SkyscrapersProfile

@WillyC yes, the use case was an import - a big migration from another CMS; I wanted to maintain a known list of tags in memory for efficiency, rather than sending an airplane to fetch all tags again and again - you know, for the climate's sake ? But anyway, it's fine. I suppose I could have maintained my own vanilla array index instead of a PageArray but I thought I was being cool using the new tools, until I found out it's a tractor. Anyway, tis done now. @flydev thanks, but that requires me to know that there aren't two distinct items: "system change" and "change system". At first I posted because I thought there might be something I was missing (like WireArray::setCaseInsensitiveMatching() or such). But then as I dug into it I found that the limitations are hard coded. None of the help/docs pages I read have any warning of this; there's many examples of chaining from a db query ($pages->find()) into some other filter without warning. I think there should be warnings in the docs about the different implementations, when suggesting filtering on a WireArray, as opposed to a $pages query. I think there should be an equals operator that is explicitly case insensitive. (though perhaps we've exhausted every combination of symbol already...!) I think the codebase should be updated to be UTF-8 compatible so that É matches é, for example on the case-insensitive matchers. But I'm too much of a noob to do PRs yet (and I have to train my editor to use tabs not spaces ?) Anyhoo, thanks for the suggestions, all.

I'm not yet sure what ProcessWire could do here since it's the template file that controls all the logic of what gets output. But I may not yet fully understand the request, so I'll use an example or what I do understand below. Markup Regions don't have control over what your template file spends time rendering, just what gets output at the end. So there wouldn't be much benefit to having output of partials when it still has to spend the time to render everything, whether used in the output or not. Instead, you would need some logic in your template file in order to selectively render partials, and gain a performance benefit from it: <?php namespace ProcessWire; // render just $part if requested, otherwise render all parts $part = $input->get('part'); // i.e. header, content, footer ?> if($part == 'header' || !$part): ?> <div id='header'> ...header markup... </div> <?php endif; ?> if($part == 'content' || !$part): ?> <div id='content'> ...content markup... </div> <?php endif; ?> if($part == 'footer' || !$part): ?> <div id='footer'> ...footer markup... </div> <?php endif; ?> <?php if($part) return $this->halt(); ?> In the above example, if the page is requested without a "?part=" query string in the URL, then it renders everything (header, content and footer). But if rendered with a "?part=content" query string in the request URL (for example), then it would render and output just the <div id='content'>...</div>.

this worked $this->addHookBefore('Pages::save', function($event) { $p = $event->arguments("page"); if($p->id == "1599") { $p->of(false); foreach($p->table as $row) { if($row->pass == "") { $pass = new Password(); $string = $pass->randomAlnum(22); $row->pass = $string; } } } });

It also has issues like fields not having edit rights make conditions not being evaluated properly. Also, Presentation settings like "Open + Locked (not editable)" and others make it fail to work. The way it is implemented in the core is half baked, has not been taken care of for years and based on the probably wrong design decision that it can be done with JavaScript only. @Robin SYour module is a lifesaver indeed. Thanks a million!

The core show-if can only work when the test relates to values that are contained in inputfields in the Page Edit form, (e.g. "some_field=foo"). Technically there is a field in Page Edit that relates to the parent - the "Parent" (parent_id) field on the Settings tab. But that inputfield is set to AJAX-load so the value isn't available to the inputfield dependencies JS. But you can use the Custom Inputfield Dependencies module to create show-if conditions that are evaluated by PHP rather than JS: https://processwire.com/modules/custom-inputfield-dependencies/ You would create a show-if condition like this:

The rabbit hole gets weirder: it seems the SelectorEnds `a$=b` is case-insensitive - at least to simple western languages (it uses `strcasecmp` which does not handle UTF-8 multibyte characters). But that's the only one of all the selectors to use it. Though others do use `preg_match` with the `i` flag (though not the `u` flag for unicode, so probably same as strcasecmp)... and others use stripos. At this point in my digging, I thought: I'll consult the unit tests, then realised there aren't any - I've made a suggestion that tests would be a good thing (EDIT: and I see others have gone further and implemented some frameworks)

https://github.com/jquery/jquery-migrate/blob/main/warnings.md

Hello all! An sorry for lousy support with this module - I'll try to be more supportive in the future. First af all.. I haven't made move to PHP8 yet since my whole web development work has been on slow burn for a year or so but things are moving forward and I'm getting back in track and also need to start moving my customer sites to PHP8 based server. So for starters I put up my dev stack with PW 3.0.210 and noticed that it requires at least PHP 8.1 to function properly. I installed PHP 8.1.10 and emo seems to work there as is with no problems so am I missing something? My error_reporting = E_ALL so I should get all warnings.

Thanks, I pushed the fix from matjazp

I can confirm. I fixed it by adding if(typeof str == "undefined") return ""; at the top of parseValue() function in inputfields.js.

@ryan - another issue which looks like it's just core related - I can no longer view field settings (eg Setup > Fields > body) because of this error: inputfields.js?v=33g:1049 Uncaught TypeError: Cannot read properties of undefined (reading 'toString') at parseValue (inputfields.js?v=33g:1049:13) at inputfieldChange (inputfields.js?v=33g:1370:15) at setupDependencyField (inputfields.js?v=33g:1606:3) at HTMLLIElement.<anonymous> (inputfields.js?v=33g:1614:4) at Function.each (JqueryCore.js?v=1.12.4:1:4048) at a.fn.init.each (JqueryCore.js?v=1.12.4:1:1235) at HTMLFormElement.<anonymous> (inputfields.js?v=33g:1613:70) at Function.each (JqueryCore.js?v=1.12.4:1:4048) at a.fn.init.each (JqueryCore.js?v=1.12.4:1:1235) at InputfieldDependencies (inputfields.js?v=33g:1612:10) Please let me know if you can't reproduce and I'll try to provide more info, but so far it's happening on all sites I've upgraded.

Thanks for the hard work on this @ryan I mentioned this in the AoS support thread as well, but I figure it's worth a mention here too in case folks can't initially figure out why their admin menu dropdowns are broken after upgrade. If you make use of AOS's excellent "Add button to check/uncheck all checkboxes" feature, it will break the top level menu dropdowns in the PW admin (and maybe other JS). The fix is to replace: ("[data-no-checkall-checkboxes="1"]") with: ([data-no-checkall-checkboxes="1"]) in: /site/modules/AdminOnSteroids/scripts/aos.min.js

Simples: In init.php wire()->addHook('LazyCron::everyDay', null, 'batchRun'); and then in your hook: wire()->log->prune('debug', $days); where $days is set however you want In my case I aded a cronjob to access the site at night so that the LazyCron fires then.

The CSV format is so simple you can easily create a template to generate the right output. As an example: <?php header('Content-Type: text/csv'); header('Content-Disposition: attachment; filename="export.csv"'); $items = $pages->find("template=basic_page"); echo "title,url" . PHP_EOL; foreach($items as $item) { echo "\"$item->title\",\"$item->url\"" . PHP_EOL; }