BitPoet

Using .htaccess is efficient. You could, in theory, handle (nearly) everything in PHP, but this would add serious overhead, both memory and speed wise. Others have adapted the rules for NGINX, a few like me use IIS with URL Rewrite to power PW, but in all cases, it makes sense to filter and rewrite requests in the web server itself. The topic of supporting more platforms than just Apache out of the box has been brought up a few times already here in the forums. Ryan himself is not opposed to it, but he lacks the time to develop and test the rule sets, and he is of course wary of including anything that hasn't been well tested or that might end up without active support (any changes he makes for .htaccess need to be quickly adapted for other platforms). So I guess it would need a team of knowledgeable volunteers who develop the rules, adapt the installer script, test everything well and provide quick support before he considers integration into the PW project.

Perhaps you can use TracyDebugger and output (bd) whatever you pass to isChanged in your hook?

@pout: even the regular WireMail class shouldn't cause such problems, so it would be good if we could narrow the cause down. Could you check if the issue is still there if you add the following line after the one @adrian linked to: $mail->set("newline", "\n");

This looks okay. You just need to get the correct image from the page. For performance reasons, I'd build an intermediate array that groups the images by page, as you have to load each page into memory to retrieve the image. This way, you can uncache the page after you have rebuilt all its variations. Untested: $query = $this->database->prepare('SELECT name FROM FIELDS WHERE TYPE = "FieldtypeImage"'); $query->execute(); $results = $query->fetchAll(); $pageimgdata = []; foreach ($results as $row) { $query = $this->database->prepare('SELECT * FROM FIELD_'.$row[0]); $query->execute(); $images = $query->fetchAll(); foreach($images as $image){ $pageid = $images["pages_id"]; $filename = $images["data"]; if(! isset($pageimgdata[$pageid])) $pageimgdata[$pageid] = []; $pageimgdata[$pageid][] = $filename; } } foreach($pageimgdata as $pageid => $filename) { $p = $this->pages->get($pageid); $PFM = new PagefilesManager($p); foreach($data as $entry) { $img = $PFM->getFile($filename); if($img) $img->removeVariations(); } $PFM = null; if($p != $this->page) $this->pages->uncache($p); // To clear up memory early in case there are a lot of pages }

Yes, it iterates the page's assets directory, checks every file if it is a variation of the current image and, if yes, recreates it with the constraints encoded in the variation's filename.

It's not hard to implement yourself. Create a template with a PHP file where you: Parse and sanitize all relevant information from the call (page id, filename, width, height, other options/actions) Retrieve the page with the given id Instantiate a PagefilesManager object with the page as the parameter Retrieve the image by calling getFile on the PagefilesManager Call size() on the image with necessary parameters/options Call $session->redirect() with the url of the object return by the site() call Here's a quick&dirty implementation:

@apeisa: this is just for FieldtypeComments and documented on the details tab for comments fields, where it can be used.

It is possible that the admin page was named differently than the default when PW was installed. In that case, you can determine the correct name (= path) from the entry in the "pages" table for the page with id 2.

Microsoft acquired GitHub last October. They likely need to present some growth figures for the first quarter to the board. So probably no catch (in the short run).

Hi @DL7, thanks for the feedback. I'll try to find the time tomorrow to give it a spin on the latest PW version so I can hopefully reproduce the behavior.

You could experiment with Pages::added too. This would also run the code when you add a new page through the API.

@benbyf, have you looked at the first link @szabesz posted?

Adding pagination to your category template should be quite straight forward. There are step-by-step instructions and examples at https://processwire.com/docs/front-end/markup-pager-nav/

The question is if the content is really the same. If it is, and the changes are just in the PHP templates, you could use PW's built-in multi-site support and (untested): Copy the PW installation to the second site's webroot Delete the "site/modules" directory and link it to the original site's modules directory Do the same for site/assets/files Do the same for the wire directory Delete the contents of the site/assets/cache and site/assets/sessions directories Edit site/config.php, set $config->sessionName to something unique from the first site (the default is "wire", so perhaps something like "wiresite2") and adapt $config->httpHosts to match your new site's hostname(s) All done. This assumes that both sites are hosted on the same server with the web server running as the same user. If that isn't the case, you will have to either adapt file system permissions, group memberships and umasks (same server, different users) or keep your own copies of wire, modules and files directories around and sync these from the first site (in that case, you best disallow admin access in the copy through .htaccess) If you want the copy to have some unique content, the task gets a bit harder, and you might have to use some kind of export/import mechanism or a feed like you wrote. But you could cover some unique content with individual templates that only have a matching PHP template on one of the sites, and there are ways to hook into Page::viewable and decide in PHP code (site/ready.php) whether certain pages can be viewed in the current site (e.g. if a page has an ancestor that hast the current hostname or a wildcard in a certain field).

Just create an individual template for that kind of page without a PHP template file.

Before you start tweaking your .htaccess (which might be problematic if you want to share your module), how about copying the dev.php to site/templates in your module's install method and creating a dedicated page for it?

RestApi.info.json in the github repo still says 0.0.3. Did you forget to sync your local changes to github?

Just add them to the template's fieldgroup. $fg = $template->fieldgroup; $fg->add($field); $fg->save(); It is save to assume that there is only one fieldgroup, the one which you can access through $template->fieldgroup (or $template->fields, which is just an alias).

Fieldgroups currently are just an additional layer of "glue" between templates and fields, and for most they are just a few additional lines to write when assembling templates through the API. There are a few points where that additional layer can add some really nice magic to PW, but even most PW module developers never come across these. For everyone not deeply into obscure PW vodoo magic, creating a template with fields is always: Create a template Create a fieldgroup with the same name as the template Create your fields, save them and add them to the fieldgroup Save the fieldgroup Set the fieldgroup in the template Save the template Of course, you can reorder the steps as long as the objects are created before being used and saved after being changed. Yes, they are. As written above, they are just a necessary glue.

Though $input seems to be defined, or the echo before attaching the hook would show a NullPage too.

Any change if you remove the ampersand from your use() statement?

That's right, and it's something that slipped past me somehow (looking into modules.php, both a MyModuleConfig.php and a MyModule.config.php should automagically make the module configurable). Thus, my bet is on a caching issue too, and it makes sense that adding an external module config without changing the original module file goes unnoticed by PW's module cache. Incrementing the version of MyModule and refreshing the modules should work too in that case.

Your ProcessGoodNews module needs to tell PW that it is configurable by having "implements ConfigurableModule" in the class declaration.

Thanks. I'm not completely sure if I read your question right. The screencap above shows the front end form (it's just included in the backend interface on the preview tab, but it's the same as if you embed your form anywhere on the frontend).

Am I right in assuming that a call to $pages->uncacheAll() between the two parts makes it work?