BitPoet

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?

I guess it should be doable by extending WireDT accordingly and implementing fitting getDatabaseSchema and savePageField/loadPageField methods as well as making sleepValue/wakeupValue with arrayish data instead of plain strings, a lot like the Events fieldtype but without the multiple value (EventsArray) stuff. Meanwhile reproduced and working on a solution. Should be ready in a few days at most. Meanwhile, I haven't been completely lazy: DatetimeAdvanced v1.0.3 supports custom subfields and works together with Lister's subfield selectors.

Allowing the user to be changed in the template is still necessary when you use the API, though you might get by if you temporarily set the flag. Then assign created_users_id the id of Jesper. // set up your new page, then... $page->template->allowChangeUser = true; $page->created_users_id = (int)$input->post->creatorid; // or however the input is named in the form $page->save();

...with a not so little impact when building complex sites. I already know I'm going to use this a lot ? Thank you!

I guess the safest approach would be to create a new PageArray Array 3, iterate over Array 1, compare with each item in Array 2 and if not matched, add the Page to Array 3. Or, in code: $array3 = new PageArray(); $array1->each(function($pg) use($array2) { if(! $array2->has($pg)) { $array3->add($pg); } });

If you don't have different names, then localUrls with be identical. Your select will just reload the page. What you need to do is pass some kind of indicator (e.g. a GET parameter with the language id) to the server and set the user's language before the page is rendered. So you need to output something like this in your page for the language selector: <select onchange="window.location=$(this).val();"> <?php foreach ($languages as $language) : ?> <?php $url = $page->localUrl($language) . "?lang=" . $language->id; ?> <option <?php if ($user->language->id == $language->id) : ?>selected<?php endif; ?> value="<?php echo $url; ?>"><?php echo $language->title; ?></option> <?php endforeach; ?> </select> Then, in the backend (best site/ready.php), you need to adapt the current language according to the parameter and store the selection in the session to make PW remember it (untested): <?php if($input->get->lang) { $newLang = (int)$input->get->lang; if(! $languages->get($newLang) instanceof NullPage) { $session->set("currlang", $newLang); } } $newLang = $session->get("currlang"); if($newLang) { $user->language = $languages->get($newLang); } You should think hard whether you want to do that though. Google & Co. will put a massive penalty on your site if you show differing content on identical URLs. Languages are different beasts from locations. I have, e.g., some colleagues from foreign countries who are a lot more comfortable doing their shopping in English rather than in German, but they still need to see the usual Euro prices and German VAT. So you might just use a different thing than the language, e.g. a GET variable named "country" that you store in the session just like the code above does and pass that to your conversion function.