Leaderboard

Or use Duplicator which is even easier imho.

Hi guys! What do you think about something like this? Because I use this option regularly in the Windows File Explorer breadcrumb and it's very useful. The drop-down menu can display only published/visible child pages. I've tried to find how to do it as a module, but I'm not a coder with enough skills for that ... or I don't know if I can use hooks to do that ...

Moving a PW site is a breeze, even without any special tools. Here's how: https://processwire.com/docs/tutorials/installation-moving-and-troubleshooting/

I'm wondering about the intended or correct use of Wire::_callMethod(). I was tying out a hook to ProcessPageView::execute(), and I wanted to get the Page object that execute() was being called for. ProcessPageView has a getPage() method for that purpose, but it's a protected method so this doesn't work: $wire->addHookBefore('ProcessPageView::execute', function(HookEvent $event) { /* @var ProcessPageView $ppv */ $ppv = $event->object; $page = $ppv->getPage(); // ... }); But then I found Wire::_callMethod(), and this does work: $wire->addHookBefore('ProcessPageView::execute', function(HookEvent $event) { /* @var ProcessPageView $ppv */ $ppv = $event->object; $page = $ppv->_callMethod('getPage', []); // ... }); Is this a correct use of _callMethod()? Is this what _callMethod() exists for? The code comment for _callMethod() is... /** * Call a method in this object, for use by WireHooks * * #pw-internal * ...so the "for use by WireHooks" part sounds like my usage is okay, but the "#pw-internal" and the underscore prefix made me wonder if this method is only intended for use by the core. I couldn't find any mentions in the forum of anyone using it in their own code.

So I obviously misread the code when refreshing my mind. If the function is correctly caching all the things it does calculate this should be fine.

+1 for Duplicator. It has saved me so much time deploying projects.

The easiest way for you to migrate your site will probably be using an export of your site - a so called site profile. Please install the module Site Profile Exporter and and create a new export. Afterwards you can install your exported site on your new host. Just upload ProcessWire, your site profile and install it as usual.

Hello, I need to add a checkbox to the comments form to make it GDPR compliant and I guess I'm not the only one... Doing a search and looking at the FieldTypeComments module file it seems that the only way to add custom fields to the form is by copying the module to site/modules and apply the changes there. I am just wondering why the comment form is not driven by the PW form API and also why none of the methods in that module are hookable? Would be much appreciated if you could share your approaches on handling this.

Sure, this might or might not be a problem. You could also do a str_replace to inject the checkbox in your markup on the server side. But afterall all those solutions are hacky and you are right that it would be nice to have other options ?

You could inject the checkbox via a little JavaScript that disables the form unless the checkbox is checked. It's might be an ugly hack, but it might be the best solution in your case..

Thanks for the info. Hooking ProcessPageView::execute and calling getPage() seems to have negligible effect on response times. The method only executes once per page view, and getting the page object with getPage() method took an average of 0.0015 seconds in my tests. So I'm not too worried about that aspect. I'm not sure what you mean here - it might return the page object for a different page? Or some aspect of the page can be different? This gave me the same ID each time: $wire->addHookBefore('ProcessPageView::execute', function(HookEvent $event) { /* @var ProcessPageView $ppv */ $ppv = $event->object; for($i = 0; $i < 50; $i++) { $page = $ppv->_callMethod('getPage', []); bd($page->id, 'page->id'); } });

Disregarding the viability of using _callMethod() here: While I understand that ProcessPageView is awefully structured for hooks – I tried to make it work with a testing framework last year – I'd not suggest you calling getPage from your hook if you don't intend to replace the whole execute function. getPage() is not safe to be called multiple times, because it does modify global state and therefore does not return the same value on multiple invocations. Also I doubt searching for the called page multiple times would be good for your page response times anyways.

Every time this topic comes up I'm slightly worried about the relation between any community-led documentation project and the new(ish) API reference at https://processwire.com/api/ref/. This already gets (somewhat?) automatically populated based on the latest core release, and I seem to remember @ryan mentioning something along the lines of updating / releasing a new cheatsheet that would use same data. If that's really the plan, it could easily make any manually updated documentation obsolete. That being said, I'm not 100% sure that this actually was Ryan's plan – or even if it was, is that still true? Additionally it might take a long time before he gets there (he's a busy fellow, after all.) Would be great if the man himself could chime in and let us know what the current plan regarding the docs is, and if we can somehow help make that happen ? One problem with the current, auto-generated docs might be that (as far as I remember correctly) the code that generates it is also powering the (commercial) API Explorer module, which could make Ryan somewhat hesitant to share it with others – which is perfectly fine, of course, but could also mean that we can't do much to help him there. But anyway, this is mostly just guessing. I've been quite happy with the new API reference, with the main problem being that one can't switch between core versions. For us who manage and work on different ProcessWire versions (for me this means everything from 2.2 .to 3.0) that's a major downside: currently when I'm working on anything other than my own projects, where the core version is generally speaking always the latest one, it's much easier to forget the docs and dive into the codebase to see which methods were available at the time.

Several core updates this week including a new way to perform $pages->find() searches by using Field tags, a new Field tag manager, new methods added to our $input API variable, new Inputfield traversal methods, and more… https://processwire.com/blog/posts/pw-3.0.106/

I've updated the first post with info on how to run tests from the browser, so there's no need to have command line access to the server.

mine is here: https://www.baumrock.com/portfolio/ but I'm not really happy with it so I also look forward to getting inspiration ?

This is just an idea I've been playing with a while: adding support for SOUNDS LIKE operator. I'm not sure how much sense it makes in the larger context, but I'm posting it here nevertheless in case it results in something useful As a bit of a background, in MySQL SOUNDS LIKE is just a shortcut for comparing two strings passed to SOUNDEX() and as Wikipedia kindly explains, "soundex is a phonetic algorithm for indexing names by sound, as pronounced in English". In other words, SOUNDEX() converts a string to an "index" of sorts, and comparing index values of two separate strings answers the question of "do these two sound alike (in English)". SOUNDS LIKE works best with English words, and literally words, since comparing entire sentences is often much less sensible (there's no native "wildcard soundex operator" in MySQL) -- names of people, products, countries, cities, etc. are a good example where one might benefit from SOUNDS LIKE. Cases I've really wished this would've been possible have included especially name and city searches, where people tend to mistype things a lot. Yesterday I decided that this would be a cool experiment, so I applied following hack to the DatabaseQuerySelectFulltext.php and Selector.php, making "€=" the SOUNDS LIKE operator. This is wrong at many levels, but works as a simple proof of concept: diff --git a/wire/core/DatabaseQuerySelectFulltext.php b/wire/core/DatabaseQuerySelectFulltext.php index 9c6064f..421f38a 100644 --- a/wire/core/DatabaseQuerySelectFulltext.php +++ b/wire/core/DatabaseQuerySelectFulltext.php @@ -83,6 +83,12 @@ class DatabaseQuerySelectFulltext extends Wire { $query->where("$tableField LIKE '%$v%'"); // SLOW, but assumed break; + case '€=': + $v = $database->escapeStr($value); + $v = $this->escapeLIKE($v); + $query->where("$tableField SOUNDS LIKE '$v'"); // SLOW, but assumed + break; + case '^=': case '%^=': // match at start using only LIKE (no index) $v = $database->escapeStr($value); diff --git a/wire/core/Selector.php b/wire/core/Selector.php index 31748f9..fccfe8a 100644 --- a/wire/core/Selector.php +++ b/wire/core/Selector.php @@ -204,6 +204,7 @@ abstract class Selector extends WireData { Selectors::addType(SelectorLessThanEqual::getOperator(), 'SelectorLessThanEqual'); Selectors::addType(SelectorContains::getOperator(), 'SelectorContains'); Selectors::addType(SelectorContainsLike::getOperator(), 'SelectorContainsLike'); + Selectors::addType(SelectorSoundsLike::getOperator(), 'SelectorSoundex'); Selectors::addType(SelectorContainsWords::getOperator(), 'SelectorContainsWords'); Selectors::addType(SelectorStarts::getOperator(), 'SelectorStarts'); Selectors::addType(SelectorStartsLike::getOperator(), 'SelectorStartsLike'); @@ -284,6 +285,10 @@ class SelectorContainsLike extends SelectorContains { public static function getOperator() { return '%='; } } +class SelectorSoundsLike extends SelectorContains { + public static function getOperator() { return '€='; } +} + /** * Selector that matches one string value that happens to have all of it's words present in another string value (regardless of individual word location) * Just for fun I've been testing this new operator with a script like this (and using one of the most mistyped names I've seen on this forum as a test subject), to see if it works at all: <?php require 'index.php'; foreach (wire('pages')->find('title€=antti') as $k => $p) { echo $k . ". " . $p->url . "\n"; } // results look something like this: // 0. /anttti/ // 1. /antti/ // 2. /anti/ // 3. /antii/ So, what do you folks think -- is there anything in this that might be worth taking further? Can you think of a better approach to this, such as a custom fieldtype with SOUNDS LIKE support, or something? Anything else?

Hello Roych, First of all, I recommend a few things: Installing @adrian's TracyDebugger module. Makes development a lot easier, you can instantly spot issues like undefined variables and null objects, it also has support for one click online html validating and about a hundred more features to ease the "pain" I mean to help get more fun out of coding. Also, turning on $config->debug = true; in config.php is very helpful during development. Next, after a successful system or module upgrade you might want to delete files/directories beginning with a dot, in your case: /.wire-3.0.36 /.htaccess-3.0.36 /.index-3.0.36.php /site/modules/.MarkupSimpleNavigation I installed @tpr's AdminOnSteroids as it has very useful features to support development: in the Page Tree it can show the ID and templates of a page, it has a one click jump link to open template/field editor pages right from a page editor page (just hover over the lables and links appear in tooltips) so it made it easy to find my way around your template/field setup. Actually, it always makes it easy to find my way around MY OWN setups too! I also uninstalled the FrontendEditing module. Frontend editing is an advanced technique, it has its limitations and quirks, and most importantly since it injects code into your frontend it is best not to use it when learning PW. It just makes issues a little bit harder to track down. Back to your code. Things I could spot: PHP Notice: Undefined variable: title in .../site/templates/_prepend.php:6 which is: <?php echo $title; ?> and should be <?php echo $page->title; ?> First I cleaned up your code to get rid of issues of invalid html. TracyDebugger has a tool to one-click validate your html which helps a lot to pinpoint issues. Your HTML was broken, I found an unnecessary "</div>" and a "<" which were simply syntax errors. With broken HTML it might be impossible to generate a working JS portfolio. You get a collection of "portfolio-detail" templates, but in the page tree the following pages are created based on this template: children of Portfolio Kategorije children of Kategorije Which is not right when your selector is this: $portfolio_details = $pages->find('template=portfolio-detail, sort=-created'); because it collects unrelated pages. You need to add "parent=portfolio, " to get the specific pages: $portfolio_details = $pages->find('template=portfolio-detail, parent=portfolio, sort=-created'); Since your original template setup was problematic, I made changes: Changed template of page Kategorije from "portfolio-detail" to "categories" Changed template of pages Vizitke, Logo and Publications from "portfolio-detail" to "category" (I renamed Kategorije to category.) Note that it is best to stick to English when writing code and setting up names in the admin. You never know when you need to pass your code to someone not speaking your native language Similarly, when testing multilingual fields, if you put Slovenian in the English fields then you make it harder to follow your own setup, so I used English names for each "en input". The more things you do not put in the right pace the harder you find to make sense of your own site, even when "just testing things out". I did not touch the Family settings of categories/category templates but you should set them up like this: https://processwire.com/talk/topic/15842-200200200-field-texturltextarea-into-1-template/?do=findComment&comment=141413 I renamed the field category to categories, as it is a Page Reference field with ASM selects, so using plural is more appropriate. I removed the setting of "Select the template of the pages that are selectable. May be used instead of, or in addition to, the parent above.", because setting the parent to the Categories page is enough. Back to code changes: this loop is not needed: <?php //foreach ($cat_items as $item) : ?> $single->images->description->first was changed to $single->images->first->description normally I use <?= ?> when echoing single values but in that case it is not possible to temporary comment them out, so that is why I switched to <?php echo ?> It helps testing. Using title as a css class or id will not work as is can contain spaces and other special characters, you need to use the name property (Settings tab > Name in the admin): <a href="index.htm#" data-filter=".<?php echo $item->name ?>"> and in the portfolio loop, you need to output the related category name(s): <?php foreach ($portfolio_details as $single) : ?> <div class="portfolio-item <?php echo $single->categories->first->name ?> "> After making all these changes it works for me, I'm going to send my version to you in a PM soon. Note that you still have unrelated owl Carousel erros in your JS. Here is the content part of the code for anybody else who might find it useful as an example: All in all, I recommend using Tracy and AdminOnSteroids (AOS), always look for PHP errors and invalid HTML and fix them before you move forward. And always work by changing things one at a time and then test if the change really does what you want. Tracy is your best bet to do testing the fastest way possibe with ProcessWire

I recently had a revelation when building HTML emails, what's the difference between HTML emails, and HTML web pages? Other than the horrible table syntax, the result is the same, it's still HTML. This got me thinking why not use a CMS to help generate the HTML emails based on a template? Just like we using a CMS to help generate HTML web pages. We started by setting up ProcessWire (our usual CMS of choice) and added the relevent fields for the sections of the email. Then we took a previous email moved the content into ProcessWire and hooked up the code to pull that content back into the correct places. Repeater fields allowed us to have repeatable sections that are easy to add too, change order of or remove, giving us huge flexibility when a client changes their mind last minute. The speed of setting up and dealing with ProcessWire allowed us to go from concept to working prototype within a day. To use the emails, we just view source of the generated page, and copy and paste into the email system. Sometimes Litmus inliner is required to allow the email to work in Outlook, but we can run it through that before pasting into the email system. Future development could be integrating a css inliner into the generation step, to avoid using litmus inliner. Hope this helps show how ProcessWire can be used in a different scenario.

I do something similar, but instead of styling the page for the email, I have a separate template file for emails that builds the html for the email using tables and inline css and sends that directly to the list of subscribers. In my case, a monthly enewsletter is composed of several different articles (each a separate child page). The template for these child pages has a field to select what month/year the article belongs to. The email sending script queries matching articles, compiles, and sends. The possibilities are endless really

@mindplay.dk: Separation of concerns, single responsibility principle, and so on -- I get it. You seem to think we're designing these things without understanding of these principles, and that couldn't be further from the truth. I'll also assume that you understand what I was stating before, that we've tried to adopt enough flexibility so that a developer can choose to adopt these principles, while still using the module interface. But we don't want to enforce that upon everyone because it would be counterproductive design. Why? There are principles, context, audience and goals. Our context is not the same as that of the Symphony framework, for example. Our audience has crossover, but is not the same. Most module cases are relatively tiny components. We have a project goal of making module development as simple and bulletproof as possible... something that might encourage web developers to take an interest in exploring their own module development. Part of that is an original design requirement of being able to share and communicate simple modules as 1 file / 1 class, when one chooses to (as many do). The ability to be super-simple and self contained like this encourages growth for the entire ProcessWire module ecosystem. We derive a lot of benefit from this, and that was the goal. It's not at the expense of the underlying principles unless you choose to make that sacrifice yourself. Don't develop your big module using the same strategy as your small module. We don't have many implied strategies for big modules and what's probably lacking most is just the documentation to explain when and why you might take one approach over another. Don't think I'm making any claims of perfection with any bit of code or design. There is always room for improvement in anything, in any project, in any system, in any file, in any class, in any method, and so on. The definition of a bad coder is someone that thinks they've got it all figured out or something is beyond improvement. I am very far from that. As most here know, I'll defend that which is worth defending and agree on things that aren't. But there's a lot more thinking behind the design than you often assume. I feel strongly about the decisions behind our current module system, and that they were the right ones. I also have an open mind. If someone proposes something better that understands not just the principles, but the context, audience and goals too, then I welcome it.