Leaderboard

This is the exact purpose of the ProDrafts module!

When you do a $pages->find($selector) operation your selector is translated by PW into an SQL query. It's a bit of a simplification (because there some exceptions for things like "count"), but essentially this means that you can only sort by values that correspond to columns in the database. So for example you can sort by "title" because that corresponds to a column in the database. But you can't use some logic at runtime to conditionally build up a custom value based on various properties of each page and then sort by that because there is no corresponding column for that custom value. So your options are... 1. If the only way to work out the sort is to iterate over all the pages in a PageArray and you then want to paginate that sorted PageArray, you can do something like this: // $results is a PageArray that you have applied some custom sorting to at runtime $total = $results->count(); $limit = 10; // Convert page number to be zero-based $page_num = $input->pageNum - 1; $start = $page_num * $limit; // Get the slice of results for the current pagination $results = $results->slice($start, $limit); $results->setStart($start)->setLimit($limit)->setTotal($total); foreach($results as $result) { // Output result } echo $results->renderPager(); But because you have to load all the results into memory in order to sort them, this strategy is not going to scale well with large numbers of results. 2. If the sorting doesn't actually depend on dynamic input you can think about using an integer field in the template to store a weighting that you can sort by in a $pages->find() selector. You would use a saveReady hook to populate this sort_weighting field according to other field values in the page. You can use the API to loop over all your book pages to set a sort_weighting value initially. The sorting in your code didn't quite make sense to me so you'll probably need to adapt this to suit, but the general idea is this: // In /site/ready.php $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'book') { $sort_weighting = 0; if(!$page->subject) $sort_weighting = -1; if(!$page->subject && !$page->author) $sort_weighting = -2; $page->sort_weighting = $sort_weighting; } }); // In your template code $results = $pages->find("template=book, sort=sort_weighting, sort=subject, sort=cleanauthor, sort=cleantitle, limit=50");

Perhaps I'm missing something, but couldn't you do something like this in a saveReady hook? $pages->addHookAfter('saveReady', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'book') { $page->my_sort_field = implode(' ', array_filter([ $page->subject, $page->cleanauthor, $page->cleantitle, ])); } }); ... and now that your sort field (which could be a hidden text field, or a textarea if there's a lot of data, which I assume is not the case) contains a single value, you can sort results by that. As far as I can tell the only issue here is that you'll basically have the same data stored multiple times ?‍♂️ (Unless I've misunderstood you, and you actually want to keep all books that have a subject before any of those that don't, etc. But in that case a simple sort by multiple field seems enough.)

You could use site/config .php settings, eg: <?php if ($user->hasRole('dev') { // or whatever role you assign // development templates directory $config->urls->templates = $config->urls->site . 'templates-dev/'; $config->paths->templates = $config->paths->site . 'templates-dev/'; $config->urls->fieldTemplates = $config->urls->templates . 'fields/'; $config->paths->fieldTemplates = $config->paths->templates . 'fields/'; } // other users, including the public, will see the default $config->templates & $config->paths (same for fields)

Relative to version 3.0.164, this latest version on the master and dev branch (3.0.165) contains 16 commits with various minor fixes, improvements and optimizations, and it resolves 6 reported issues. Version 3.0.164 has been very stable, and this version should be even more so. Both the dev branch and master branch are identical at this moment. As mentioned last week, new versions of both FormBuilder and ProCache are in development, and I’ve been working on both of them quite a bit this week. I mentioned some of the updates being made in FormBuilder last week. Another new feature to mention is the addition of reCAPTCHA to the spam prevention tools. While our built in honeypot is just as effective (when setup properly), it does its work silently, behind the scenes, never visible to anyone. Whereas reCAPTCHA is hard to miss, which is a benefit for clients that want to to be able to literally see spam prevention measures in place. No doubt, it brings a certain level of comfort, and adds another level of authority to your forms. So I’m really glad to add it to our set of form tools. Rather than building it into the form “actions” I’ve instead built it as an Inputfield module (InputfieldFormBuilderRecaptcha), as this gives you a little more flexibility with regard to placement and customization. It is ready for download now in the FormBuilder board Download thread (login required). It can be used with any version of FormBuilder 0.3.9 or newer; meaning it’s ready to use now. If you download it, be sure to read the pinned reCAPTCHA thread in there for detailed instructions (it's very easy to setup). I’ve been talking about it for a long time, but it seems like it may finally be a good time to re-do the modules.processwire.com site. It all works just fine, but just needs an update, consistent with the rest of processwire.com. So we’ll likely slow the pace of core updates for 2-3 weeks to work on that, sometime between now and the end of the year. Thanks for reading and have a great weekend!

Yes, that's the intention. I actually assumed that these were field values, but if not, then yes — you'll have to define them here as well ? This is a little off-topic, but if/when you store custom non-field values within a Page object, I would recommend prefixing them with an underscore. It's not a big deal, but can make it a little more obvious that these are not actual field values. Also, ProcessWire will never save a property such as $page->_some_key to the database, so this way it's impossible to accidentally overwrite some *real* (field) value.

Just wanted to make a note here that I just wasted several hours trying to debug why I couldn't manually add or delete rows from a table when this module was installed. Turns out it was PHP's max_input_vars setting being too low, but no error was being logged anywhere. In the process of debugging I did fix a few bugs related to Table fields inside Repeaters and some other cleanup, so perhaps it was a worthwhile waste of time after all ?

It's already possible to list commercial modules ? For example Padloper: https://modules.processwire.com/modules/pad-loper/ Or dynamic selects: https://modules.processwire.com/modules/process-dynamic-selects/

Yes, that would be the solution. Maybe IMagick is better but in this case I have to use GD…

This may seem like a hackish workflow proposal, but you could just as well clone the production page, unpublish that copy, and work on that. If the clone is ready to be published, publish that one and hide / unpublish the other. Just bear in mind to adjust the page names and -names to avoid ugly looking URLs like /section/my-page-name-copy and 404s.

Sorry, if I didn't understand your case, but if you are looking for a survey tool I can recommend LimeSurvey. Of course you could do this with ProcessWire, but a survey tool has most of your points already covered. ?

@Knubbi that's a question for Ryan in the ProDrafts forum ?

This could be of interest: https://stackoverflow.com/questions/59998409/error-code-3685-illegal-argument-to-a-regular-expression Maybe file a bug report here, (if you think you've found one, i.e.) https://github.com/processwire/processwire-issues

We do have "version control" but it doesn't hide the latest (work in progress) version. It's kind the other way round. P.S.: Just found, that we do have a ProDrafts license. Any insight, when this might be included in ProDrafts (Quote of description "In addition, fields using a type of Repeater or PageTable are not currently supported for drafts (though support is planned).")?

@psy No idea, I haven't used ProDrafts yet. Though unless I have misunderstood the question, this question is about having public and draft versions of a page's content, not different versions of it's PHP template. So I don't think your suggestion applies to this use-case?

@teppo The directory should be updating version numbers from a getModuleInfo() method, but I think it may have issues when the version number is in an info.json file. This'll definitely get fixed in the update, likely before. Thanks.

While you're at this, perhaps you could take a look at this as well: https://github.com/processwire/processwire-issues/issues/988. I haven't checked recently, but at least back then the modules directory wasn't updating the module version (note that this was unlikely to be caused by normal delay, as the version number hadn't updated in months). Thanks ? Just in case I've been updating the version numbers for all my modules manually. It's not a huge deal, but would be better if the automation worked (though again, I haven't done any tests recently, so maybe this was already fixed.)

@Zeka That's correct. V4 is split out into a bunch of different classes like this, as ProCache has grown quite a bit. It's possible I might not understand what you mean. But ProCache only clears cache files that exist. It knows ahead of time which ones exist because there's a corresponding DB table entry for every cache file. So it shouldn't attempt to find or clear files for any languages that don't have the content available in the cache. Meaning, so long as the page isn't published in the language that it lacks content in, ProCache isn't going to be attempting to write or clear cache files for that page in that language it's not available in (i.e. no extra overhead). But if what you are looking for is more logic in determining whether a page is cleared for a particular language, that clearPage() call in the earlier hook I mentioned does also accept a 'language' option which limits the clear to a particular language. You can also tell it to clear only a particular URL segment, or segments matching a wildcard pattern. Here's the options for the clearPage method: /** * Clear the cache for a specific page * * Default behavior is to clear for all languages, paginations and URL segment variations. * To clear only specific languages, paginations or URL segments, use the options. * * @param Page $page * @param array $options * - `language` (string|int|Language): Clear only this language (default='') * - `urlSegmentStr` (string): Clear only entries matching this URL segment string, wildcards OR regex OK (default='') * - `urlSegments` (array): Clear only entries having any of these URL segments (default=[]) * - `pageNum` (int|bool): Clear only pagination number (i.e. 2), true to clear all paginations, false to clear no paginations (default=0) * - `clearRoot` (bool|null): Clear root index of page path? (default=false when URL segments or paginations requested, true otherwise) * - `rmdir` (bool): Remove directories rather than index files? (default=false) * - `getFiles` (bool): Get array of files that were cleared, rather than a count? (default=false) * @return int|array Quantity or array of files and/or directories that were removed * */ I think we've got all the tools we need to support that kind of logic on the hook side, but ProCache doesn't do that automatically at present. It's a good idea though, I can explore it further.

Seems that things changed slightly ? This worked for me today: Translate file /wire/modules/Inputfield/InputfieldDatetime/types/InputfieldDatetimeText.php Set path: /wire/modules/Jquery/JqueryUI/i18n/jquery.ui.datepicker-de.js Search keys: datetime, date picker, monday, translate, sunday, german

You will need: ProcessWire (of course) ProcessWire ProCache ProcessWire Modules as you like and need Netlify Account (in my case, you can use any other hosting or Github pages) Git Account (Gihub, Gitlab, Bitbucket) ScreamingFrog (free version should fit most needs) Things to keep in mind FormBuilder will not work (out of the box) 40x/50x must be defined separately Redirects must be defined separately Module-based functionality will not work GDPR/Opt-in/Cookie consent must be added differently Avoid using core/module files (UIKIT, jQuery, CSS, etc.) Where to save files and how to address them Most content and design related files can be saved in ProcessWire itself. Logos, favicon, trust icons and whatsoever. Some files can't be stored in ProcessWire - or shouldn't be stored in it - fonts and sitemaps (XML) in my case. While developing the overall site always use relative paths and URLs. Fonts and other assets need to be addressed by their web-root-based path (/site/templates/myassets/font.ttf and so on). Internal linking should be relative as well. Otherwise you have to change those link URLs manually which is PITA. Which files to copy and where you find them As we use ProcessWire we want and should use everything we can to make our webdev life easier here. Let ProcessWire and some modules do the work while harvesting the results for our benefits. While ProCache takes care of generating minified CSS and JS, SEO Maestro generates a nice and handy sitemap.xml. Depending of your installed modules you want to (at least) double check the output and results in your static site. As already mentioned FormBuilder and Simple Contact Form will not work, 404 management and redirects by the awesome Jumplinks modules will not work, too. Instead you have to create your very own .htaccess file with all redirects and error documents. Other modules like MenuBuilder, SEO Maestro and some other modules do a pretty good job even in your static site as their benefits result in already rendered HTML/pages. Autolinks, Automatically link page titles and Share buttons are some modules that will work as well. While it didn't work for me it may work for you - the Cookie Management Banner module. I had some issues and decided to install and use Cookie Consent manually. The Workflow First of all build your site. Make it perfect. Do whatever you or the client wants or needs. Whenever possible look into your rendered HTML and cached pages. Take a closer look at all the URLs and paths. It's already a good idea to run ScreamingFrog and find out if there are any files missing, links broken or pages missing. When everything is done, clear all cached files, all minified JS and CSS. Start a ScreamingFrog session and let it run. It will visit each and every page on your site it can find. Hidden pages, orphaned pages and of course drafts and pages behind JS-links will not be found and therefore cached by ProCache. Look into /site/assets/ProCache-XXX/ and /site/assets/pwpc/ now and double check that there are your pages and JS/CSS files. You will need those afterwards. If everything is fine you have to copy things around now. The Setup - folders and structure In my case the easiest way to go was setting up two local sites - one with ProcessWire and another one with the static files, assets and other things I needed. In the examples below only relevant parts are listed. project.pw.test (ProcessWire) /sitemap.xml (Generated by SEO Maestro) /site/assets/files/ (copy the whole path) /site/assets/pwpc/ (copy the whole path) /site/assets/ProCache-XXX/* (copy only the content of this folder - all files and folders) /site/templates/myassets/ (copy the whole path) project.sv.test (Static version) .htaccess (for redirects and 40x/50x error pages) 40x.html 50x.html /sitemap.xml /site/assets/files/ /site/assets/pwpc/ /site/templates/myassets/ all files and folders from /site/assets/ProCache-XXX/ As you can see there are only a few things to copy. When you're done with copying these files to the static version of your project, open it up in your browser. Check for missing files and test it. Let ScreamingFrog do the most work and check for any kinds of errors. Fix them in your ProcessWire-site and copy and test again. Check your 404s, your redirects and everything else you would normaly test. Create checkafterupdate.txt and write down whatever went wrong in your first try. This will be a great checklist later. The Final Step As everything is copied now and at its correct place you can upload it to your host. In my case the static version is a private git repository on github.com. I can commit and push my changes there and Netlify takes care of publishing the new version - most of the time within seconds. The benefit of using git - compared to S/FTP - you always have some kind of control if something brakes and you have to revert and check changes. In my case it's Netlify but you can use Github pages or any other hosting solution you want/the client pays for. Be careful with GDPR-related things as DPAs. You have to have them in most cases - Netlify did a great job here and I found everything I needed, while Github disqualified itself back then due to missing documents and kind of a sluggish support. Questions? Ask.

As I understand it, „I prefer“ is not equal with „I never do“ or „I always do“. A single decission may be a compromise related to: possibilities, „costs“, and possibly available manpower compared to expected time expenditure. ?