LMD

I have never used Stripe before, but I am wondering if it what I need for a client... Does Stripe allow sellers to charge the buyer's card when items are shipped (which could be several days/a week later) instead of immediately when an order is placed? I am not talking about invoicing. As far as the buyer is concerned the process is a regular shopping cart experience, except their card won't be charged immediately. If it doesn't, is there any UK available payment gateway that does? This is for a small-scale business with <£300 per month of online sales (they are mostly a "bricks and mortar" store). I'm asking in the PW forum, because if it does, I'll be looking to use Padloper as the shopping cart. Right now my client is locked into Woocommerce and a discontinued CC (PCI compliant!) payment processor.

That, and many other reasons, is why I use one ?

To use a namespaced (or non-namespaced) class inside another namespaced file, you need to add a slash ('\') before the included classes' namespace. Otherwise, it is looking for the class relative to the file's namespace. While it works -- and in this instance doesn't appear to cause issues -- removing a file's namespace negates the reason for using namespaces in the first place. Here is an ammended version of your code: <?php namespace ProcessWire; class ProcessSocial extends WireData implements Module, ConfigurableModule { public function init() { $file = __DIR__ . '/vendor/autoload.php'; if (file_exists($file)) { require_once $file; } } protected function testFeed($user){ // Note the '\' before 'GetStream' $client = new \GetStream\Stream\Client($api, $key); $feed = $client->feed('User', $user); return $feed->getActivities(); } } If you find you are calling a class a lot, then you can use a 'use' statement at the top of the file, like this example: <?php namespace ProcessWire; use \GetStream\Stream\Client; // Namespace path to the classname (inc. the classname too) class ProcessSocial extends WireData implements Module, ConfigurableModule { public function init() { $file = __DIR__ . '/vendor/autoload.php'; if (file_exists($file)) { require_once $file; } } protected function testFeed($user){ // Now you don't need to add the namespace at all here $client = new Client($api, $key); $feed = $client->feed('User', $user); return $feed->getActivities(); } } Hope that helps.

Another approach I use on my local dev environment, for completely unrelated projects on different hosts, is to simply symlink the 'wire' folder. My Setup/Structure: /www <-- my localhost root (I'm using Laragon). /processwire <-- folder dedicated to ProcessWire projects. /wire <-- the ACTUAL location of the wire folder that the symlinks point to. /project_a <-- each separate project (treat this folder as the web root: http://project_a.localhost/ ) /site <-- the project's ProcessWire /site folder /wire <--- this is a SYMLINK to the /www/processwire/wire folder /.htaccess <-- the ProcessWire .htaccess file. /index.php <-- the ProcessWire index.php file. /...etc <-- any other files that you'd put in the web root of a project (robots.txt etc). /project_b <-- same folder/file structure as above When I want to update the ProcessWire version, I just download it and copy the 'wire' folder over into /www/processwire (I actually rename the old folder, copy over the new and check everything works before deleting the old folder). Adding a New Project My process for adding a new project, we'll call it 'project_c', is then: Create the project in the ProcessWire projects folder: /www/processwire/project_c Create a local url for the project (http://project_c.localhost/) and point it to the newly created folder above. In the 'project_c' folder, unpack a copy of ProcessWire (the same version as the current shared wire folder for simplicity). In the browser visit http://project_c.localhost/ and run the installer as usual (& create the DB). Once installed successfully, delete the /www/processwire/project_c/wire folder (or rename it and delete later if it all works ok) and create a symlink to the shared 'wire' folder. The advantage of this for me, is that it does away with the need for naming the site folders 'site-project_a', 'site-project_b' etc.

There are probably as many ways of doing this as there are people who use ProcessWire, but this is how I would do it based on what I understand of your set-up. On the template: <?php // Just include one partial here (the HTML code in 'block-sidebar' and 'block-sidebar-settings' appears identical) include('views/blocks/block-sidebar.php'); ?> Now in "block-sidebar.php" <?php $aside = page()->aside; // first get the current page aside if ($aside === "") { // If the current page aside is empty, try and get the settings aside $aside = $pages->get('1032')->settings_aside; } ?> <?php // Only show the entire block of code if $aside is not empty (if neither the current page nor settings have content) if ($aside !== "") : ?> <div class="uk-card card-bg uk-padding-small uk-margin-small-bottom"> <h6 class="uk-margin-remove uk-text-uppercase uk-text-normal" style="letter-spacing: 1px; margin-bottom: .5rem !important;"><span uk-icon="icon: info"></span> Aktuelles</h6> <?=$aside?> </div> <?php endif; ?>

I do not understand what you were trying in your examples -- I think maybe you are muddled about how $sanitizer works? All it does it return the sanitized value. All you need to do is this: $activepost = $sanitizer->selectorValue($page->title); $articles = $pages->find("template=post, cbpage2=$author, limit=2, title!=$activepost, sort=-cbdate" ); /** * OR: in case you need to use it unsanitized elsewhere */ $activepost = $page->title; // note the position of the sanitizer method $articles = $pages->find("template=post, cbpage2=$author, limit=2, title!=" . $sanitizer->selectorValue($activepost) . ", sort=-cbdate" ); /** * OR (again): if $activepost is only used in the selector, you can ditch it altogether and use $page->title directly */ $articles = $pages->find("template=post, cbpage2=$author, limit=2, title!=" . $sanitizer->selectorValue($page->title) . ", sort=-cbdate" ); */

@biber No problem, we've all been there at some point.

Did you remember to update your password to the new one in your ProcessWire config file (/site/config.php)?

Another like for the CKEditor plugin custom folder change! Regarding the download page of the website: I suspect this may have been mentioned before, but the displayed version still appears to be stuck on 3.0.174, when we are actually on version 3.0.178.

@ryan This is an excellent addition to the core. For a particular use-case I have, I am wondering if something is possible -- either something already possible I've overlooked, or as a feature request. Sometimes it is useful to have the page info when building a selector for a page reference field — so I was wondering whether it could be possible to use placeholder tokens to pass the current page being edited to the ajax request? For example, in the "Text Tags" section of the field setup, we could enter something like this for the "Ajax URL" : /find-fieldname/{page.id}/?q={q} Where "{page.id}" is replaced with the ID of the page being edited at runtime. Similar to other places in the PW admin where we can insert placeholder tokens. Then in the hook itself, we have: $wire->addHook("/find-fieldname/([0-9]{4})/", function($e) { $pageID = $e->arguments(1); // ... the rest of the code }); I'm using page ID as an example, but it could be any valid page or template variable.

UPDATE 20 Apr. 2021: This issue has now been fixed. I have just encountered the exact same issue here when trying to paginate a PageArray which has autojoined fields -- without autojoin the pagination works as expected, with it getTotal() shows the wrong number. This is with the newest DEV branch version of ProcessWire: ver. 3.0.175

I had a thought about findRaw from a use-case I have (a flag set on pages via $page->meta() on save). I don't know how feasable it is, but it would neat if it was possible to join the contents of 'pages_meta' onto findRaw/getRaw queries. Nothing fancy, all it would need to do is return the raw data (just like any fieldtype that gets joined) as an array indexed by meta key. $p = $pages->findRaw('template=foobar, parent=1234', ['title', 'pages_meta']); /* Would return, for example: [5678] => [ 'title' => 'The Page Title', 'pages_meta' => [ 'foo' => 'Plain String', 'bar' => '{"a":"JSON","b":"String"}' ] */

I never did like October ? ! I've fixed the code.

Oh my, this is excellent! A first use case I thought of was archives (eg. blogs) filtered by date: YYYY/MM/DD /** * This example merely displays back the selected date as a string, but it could be used to show date-based archives. * The following URLs are valid: * /YYYY * /YYYY/MM * /YYYY/MM/DD */ // Build basic date regex to eliminate very silly things (e.g. 2021/15/92) $dateRegexY = '(year:\d{4})'; // any four digits (could be narrowed, e.g. '(19|20)\d{2}' $dateRegexM = '(month:(0[1-9]|1[0-2]))'; // 01-09 or 10-12 $dateRegexD = '(day:(0[1-9]|[1-2][0-9]|3[0-1]))'; // 01-09, 10-29, 30-31 (will need further validation!) // Put it together $dateRegex = '/' . $dateRegexY . '(/' . $dateRegexM . '(/' . $dateRegexD . ')?)?'; $wire->addHook($dateRegex, function($event) { $date = $event->year . ($event->month ? '/' . $event->month : '') . ($event->day ? '/' . $event->day : ''); return $date; }); The possibilities are endless.

Without needing to buy a Pro module (although they are excellent!), there is indeed a ProcessWire way for this. You can use $files->render()/wireRenderFile() to achieve what you want: https://processwire.com/api/ref/wire-file-tools/render/ https://processwire.com/api/ref/functions/wire-render-file/ The advantage of using this over your own functions is that it will automatically keep access to all of PW's API variables (no need to pass them in). Here is a simple example based on your use-case description: /** * In your generic template file. * Note: it assumes there is a directory under 'templates' called 'layouts' (it could be called anything). * Just create your layouts in the 'layouts' dir and name them the same as the '$item->template' names you are using. */ // Get the content of the specified layout into a variable. // This example looks for '/site/templates/layouts/name-of-template.php' (the .php extension is assumed) $pageContent = $file->render('layouts/' . $item->template); // Just echo it out wherever you need it. echo $pageContent; Read the docs on it, there is more you can do with this method/function, including passing custom variables, and some other options to make it more flexible. There is also a $files->include() method which is the same except it directly echos out the content instead of returning it to a variable.

Thanks Ryan, the update fixed the problem.

This is great, but I've encountered a possible bug, unless I'm doing something wrong. As a test I used it to create a simple site map using a recursive function -- besides the page title, I also wanted a 'headline' field, so it seemed a good candidate for an autojoin test. When I ran it, however, there were some unexpected results (missing child pages and missing page names in urls) with the autojoin feature. Here is the plaintext output from my tests (correct version first, then the incorrect version): Notes: C = hasChildren / numChildren (same result) $p = current Page object being traversed In both cases, the sort order is default (manual sort in the backend). All pages use the same template (so definitely contain the fields being autojoined). In all cases, both the 'title' and 'headline' fields were present in the output, so I omitted them below. This is the recursive function I'm using: // Called with: siteMap($pages->get(1)) function siteMap(Page $p) { $str = ''; $children = $p->children('join=title|headline'); // with autojoin // $children = $p->children(); // without autojoin foreach ($children as $c) { $str .= $c->id . " " . $c->hasChildren() . " " . $p->id . " " . $c->url . "\n"; if ($c->hasChildren()) { $str .= siteMap($c); } } return $str; } The following methods all produce the same incorrect results: $p->children('join=title|headline'); wire('pages')->find('parent='.$p.', join=title|headline'); wire('pages')->findJoin('parent='.$p, 'title,headline'); wire('pages')->findJoin('parent='.$p, ['title','headline']); Furthermore, it made no difference if I used "field" or "join" as the keyword in the selector. ProcessWire 3.0.172 (DEV) PHP 7.2.0 MySQL 5.7.19

[Edit: I probably should have tagged @gebeer.] Hi, I came across a use-case today that I wondered if it would be possible to add? It would be super useful to have the option to include child pages in the "Pick from the page being edited" and also "Pick from any page" source options. Furthermore, it would really useful if, when "include child pages" is selected (for all source options), the parent page being edited itself did not need to contain an image field. My use case is the following set-up: Gallery Collection 1 <-- contains 'image reference' field, but no 'images' field of its own. Album 1 <-- contains the 'images' field for a group of related image (e.g. different view of the same object). Album 2 Album Collection 2 Album 1 Etc... The parent "collection" template has an image reference to choose an image from one of the child album templates to serve as its "cover image". It would be even cooler if, as well as specifying the images field to select from, you could also specify images having a particular tag (if tags are used). But that might be asking for the moon ? !

Thanks. I will look more closely at CroppableImage.

@Robin SThank you for a perfectly timed module! I have a wishlist suggestion - as well as the fixed ratios, would it be feasible/possible to also include a minimum size for the crop area? For example, a banner image (used in your own screencast demo) might have a minimum width requirement. It is easy to shrink a larger cropped area, but obviously, a smaller area can not be "embiggened" without pixelation. Maybe it could be specified along with the ratio (e.g., using a comma): Banner Image=2:1,800:400 Technically, you'd only need to specify the length of the longest side.

Oh, sorry, I don't have a RepeaterMatrix field in operation anywhere at the current time.

Works like a charm for me, both outside and inside repeaters. Thank you, @gebeer!

No, it's in my dev environment and I'm the only user (superuser). While I think of it, I also ensured the pages were 'published' and not 'hidden', in case that was the problem (it wasn't).

Hi @gebeer, I tested the update this morning and oops... I don't know what happened this time, but it no longer works at all either inside or outside of a repeater. it just loads a clone of the page currently being edited. It's hard to explain, so this GIF should illustrate what's happening (this is a test outside of a repeater): The above demonstrates the "choose an image from page" and "choose any page" options. The field settings are correct - they are same ones that worked (outside of a repeater) previously. There are images available! I tried the other options (from a folder etc) and exactly the same thing happens. I uninstalled all other modules in case there was a JS conflict and still the same thing happens. In case it helps, here is the console log: I'm using ProcessWire version 3.0.147 and PHP 7.2. Happy New Year! (?)

Hi @gebeer - thanks for this module. I'm having an issue when using it with repeaters, though. Previously I used the "FieldtypeImageFromPage" module which worked perfectly in repeaters, but swapped to this more flexible module and now get the following errors which prevents the field working (no image picker section available -- see screenshot after): Notice: Trying to get property 'data' of non-object in \site\modules\FieldtypeImageReference\InputfieldImageReference.module on line 58 Warning: Invalid argument supplied for foreach() in \site\modules\FieldtypeImageReference\InputfieldImageReference.module on line 58 As you can see, there is no way to pick an image (clicking on the blank area does nothing) -- the field is set-up correctly, because it works outside of a repeater without problems! I think the problem is that the module is getting the field settings data by fieldname, but of course, in a repeater the fieldname is changed to "fieldname_repeater####", causing the issue. It appears to be this line (58) : foreach($this->wire('fields')->get($this->name)->data as $key => $value) { In a repeater, $this->name is looking for "fieldname_repeater####" which returns a non-object, making the foreach bork.