Leaderboard

Not sure about anything beside what @kongondo linked, but PW does definitely cache things, both field values and pages. Pages are kept in memory as any calls to Pages::get and Pages::find are routed through PagesLoaderCache. Equally, field values are retrieved only once, as Page::getFieldValue (which is in turn invoked by other get... methods like getUnformatted) only calls Fieldtype::loadPageField if the raw field value isn't yet populated (and $page->fieldname and $page->get('fieldname') both delegate their work to getFieldValue).

I haven't yet but I'll give a try.

Use the "Custom find" or "Selector string" options to define the selectable pages for the field, and specify a "sort" in the selector, e.g. "sort=title".

It's done, will be added to the next aos update. I've borrowed some code from @Robin S modules (thanks!) as I haven't added config inputs to fields so far. In fact I totally forgot about this asmSelect snippet of mine, thanks for the reminder

Anything in a Process Module tagged executeXXX is a page (not a physical one though, but a URLSegment). So, if you have executeTesta, and visit /log-in/module-name/testa/, if there is nothing being returned there (a string output), you will see the error, Process Returned No Content. Not really. There is no correct location. You can have the form in execute() but handle the Ajax request in executeTesta() or wherever you wish. These virtual pages (executeXXX()) offer a lot of power and versatility. All you need to tell the Ajax call in jQuery is where url is. So, you can do url:/log-in/module-name/testa/ and you will be able to handle the Ajax request in executeTesta() :-). You can even have executeTesta() do nothing but handle Ajax requests (maybe rename it to executeAjax(). If the page is accessed directly (i.e. non-ajax request), you can have it redirect to execute(), otherwise (if Ajax sent), process it. In a nutshell, you make the decision about what works for you. ProcessWire doesn't really mind

I haven't thoroughly tested this (nor fully read the post you linked to) but it works. Edit/Note: code be will be updated in line with the changes in OP. See new post below In /site/ready.php $pages->addHookAfter('save', function($event) { // get the page object saved $page = $event->argumentsByName('page'); // only on pages with a temporary parent (old template) if($page->template !='old-template') { $this->message('page has wrong template'); return; } // if page still unpublished return if($page->is(Page::statusUnpublished)) { $this->message('page still unpublished'); return; } // good to go; assign new parent and template $page->parent = '/new-parent/'; $page->template = 'new-template'; $page->save(); $this->message('page template and parent changed'); }); Messages in there are for testing. Edit as needed

I started to make that LDAP stuff more generic but got a bit overtaken by changing realities, but I'll take a look and see what I can put together when I find a minute. I'm letting the server itself do the authentication (with IIS not really much to configure) and just let PW take care of authorization. The same can (and used to) be done with apache and an ldap/sasl/kerberos auth module as well. The essential part then are the script that import the users (that one should probably take all configuration from the module, something else I'll take a look at) and relevant groups (using the famous UserGroups module). One of the nice things about PW is that most information (and code) is still current after a few years So stay tuned.

Old topic below but might provide some insights

@tpr - have you considered adding this functionality to AOS? Or maybe a @Robin S "limit" special module

Maybe you can use multi-instance functionality for permanent storing of test data in separate DB? https://processwire.com/blog/posts/multi-instance-pw3/

Not out of the box, I don't think so. A user is a page like any other page. They share the same parent, Users (ID 29). You cannot have more than one page with the same name under the same parent in ProcessWire.

Not a question, but just something I discovered that I wanted to share on the forum since I haven't seen it discussed anywhere. If you are familiar with the "autojoin" option on individual ProcessWire fields, enabling this feature means that every time a page with that field on it is loaded into memory, the field will be included with it immediately. (Normally just the page's name and meta data is included, and getting a specific field from the page requires a separate trip to the database. This is to conserve memory) Normally this is fine and it keeps things simple, but occasionally you may be loading a lot of data in a consistent fashion (for, example, to populate a table) and know exactly which fields you need. With the autojoin option on fields, you would have to enable autojoin for all pages at all times, which you probably don't want. With the following code, you can do a $pages->find() and specify exactly which fields you want to autojoin with it: $pages->find("template=whatever", ['loadOptions' => ['joinFields' => ['filed1','field2','field3']]] ); I tested out in debug mode on one of my projects, and it seemed to significantly reduce the number of SQL queries required for an html data table I was building. Hope that helps someone!

Yep, well took a bit longer reading the doco, experimenting etc and my site was already live. Now I know how to do it, will only take 15 minutes next time. Steps: Create your icons. I only had up to 256x256px. That's old hat. Now you need up to 1024x1024px. Decided to go with my existing website/app icon set anyway. Go to http://www.manifoldjs.com/generator and fill in the blanks Generate the files, download the kit, edit the files and/or your PW template(s) required and upload to the root directory, not /site/ directory, of your ProcessWire site Woohoo!!! Works great with a couple of provisos: The online builder does not work for Mac, iOS and Windows 10 devices, only everything else. Found it somewhat ironic it lacks Windows 10 support as this is a Microsoft product. No surprises there! For Mac, iOS and Win10 you have to use the PWABuilder CLI, almost formerly ManifoldJS CLI as it's going through a name change. Would be ever so grateful to anyone who can tell me how to do that. Followed the instructions to the letter, and also multiple variations, and could not get the CLI version to install/work and I definitely have the latest versions of Node and npm. PWABuilder delivers a manifest.json file and a couple of basic service workers, without all the fuss associated with SPAs, REST APIs etc, for small, informational websites. Watched a video recently that amongst other things, stressed PWA != SPA. Took me a while to get that. (Tip: skip the ads) While not yet perfect, PWABuilder was a good introduction for me to PWAs for ProcessWire.

@tpr Fantastic! Great addition. @adrian thanks for suggesting.

Hmm, the Author Field is blank..(in the module's page).

@tpr - that's what I call service Thank you!

Why are you placing view restrictions on the "hide_year_of_birth" field? Isn't it the "birthday" field you want to limit view access for?

https://modules.processwire.com/modules/mail-debugger/

Ahem (put disclosure here ).... https://modules.processwire.com/modules/process-dynamic-selects/

Do you need to actually update the sub-domains in the sense that you want to save to their databases OR Do you need them to reflect some changes made to the central site? (i.e. changes made and saved in central site database) If #2, the you can pull the changes made in the central website and display them in the sub-domains using ProcessWire's multi-instance feature Actually, if #1, you can also use multi-instance but that will need a bit more work since you will have to be saving to sub-domains as well. What sort of updates will these be? Text? What about the fields, complex (like Repeaters) or Text inputs? You will also need to decide on what triggers the 'fetching' or 'pushing' of new data from/to the sub-domains. Cron? Web views? You could also use REST API for this. In a hurry, hope above make sense.

I meant what you see in Chrome (or Firefox) Dev console (not Tracy, although Tracy can show you responses [not just calls] to Ajax calls). Add the following code to the place (in your module) you are expecting to receive the Ajax request. Then, open the Chrome console ( still viewing your page with the form), head over to the Network menu item and onto the XHR tab then execute your Ajax call. if ($this->wire('config')->ajax) { echo "Ajax post received"; exit; } In the XHR tab, inspect the response of the Ajax request sent to /log-in/moduleName/. Do you see the message "Ajax post received" as the response? I suspect you will not, because I think, you have your ajax response code in executeTesta() which is a different page within your Process Module. Its URL is /log-in/moduleName/testa/. I think that is what is happening. You are posting to the main page of your Process Module but checking for the ajax response in another page (Testa)...or the other way round

Welcome to the forums @Mikael, Here's a simple explanation of Dos and Don'ts (regarding MPL 2.0): https://tldrlegal.com/license/mozilla-public-license-2.0-(mpl-2) So, yes, you can modify it as you wish. As the summary at the above link, you have to: Include Copyright Include License Disclose Source Etc

@Robin S I fas as know they are cached somehow, but I don't remember where I'he read it. Only first usage results in DB query. Actually, you can check this behavior by looking at PDO queries count in PW debug panel. Also would like to get more efficient answers.

$first = $selectWatch->eq(0); $second = $selectWatch->eq(1); $third = $selectWatch->eq(2); https://processwire.com/api/ref/wire-array/eq/

You could use another field, login via email or title, but even then there is the problem: User 1 has password: 123456 User 2 has password: 123456 If you search the same name/email at login and loop with the password on found users, then user 2 could login into user 1 account. This would be bad. The possibility is there to have the same password, and you can login into the wrong user account.

Three options to get the discussion going Bootstrap either ProcessWire or your eCommerce App. The one being bootstrapped stores the user data REST API: The eCommerce App can request and receive user data using REST or similar (@see ProcessWireGraphQL) Invest in the native ProcessWire eCommerce app, Padloper .

Nice tip! You can also turn autojoin on and off for selected fields whenever you need via API methods $field->addFlag(Field::flagAutojoin) and $field->removeFlag(Field::flagAutojoin).

I’ve seen it once or twice before, and also recall that something else was going on. Sometimes it’s due to an apache misconfiguration with the virtual host (happened to me often on my old local development machine, before my PW days), and other times it’s module related. So I think you should explore those (disable one by one to see what happens) and make everything is “a-okay”. Failing which, someone else might need to chime in and assist.

Looks like it handled required fields right from the start.

How about DateInterval::format it's stupid -.- Maybe this: https://github.com/kevinkhill/php-duration

This functionality is now available via the "Delete Unused Fields" action in my new Admin Actions module:

I got a client request to make Word template so she can create an image of the weekly menu of a restaurant to post on Facebook. I usually get sick when I have to deal with M$ Word - it's frustration and it's not meant to be used things like that. So I figured out a better system: PW + html2canvas.js. It took more time to finish but it was worth the trouble. The main issues were html2canvas versus some CSS issues, plus switching to different languages in PW on each line. Also, JavaScript cannot offer named downloads, only "download.png", so I had to use HTML5 attribute "download" on links to be able to add custom download filename. I used ProField modules Table and Matrix Repeater which allow very pleasant editing of menu items, even in multilanguage context. Front-end editing is created using the built-in front-end editor. I was about to achieve inline editing of menu items but it soon turned out that repeaters and tables can't be edited this way. Anyway, it's still better compared to my module FEEL because sections are reloaded using Ajax and the admin lightbox shows only the fields I choose. Here's a quick screencap - when the gray background turns to dark gray, then the menu is not HTML but canvas, that can be downloaded.

Any ideas how to stop it minifying the spaces in CSS calc?

What are you using on localhost and the other server? On (Laravel's (?)) Forge, Nginx is used, not Apache apparently. Edit: so you are (perhaps) using Digital Ocean on Laravel's Forge, which is where it doesn't work? But you mentioned another server where it works, which one is it? There are perhaps some tweaks that are needed.