Robin S

I might be misunderstanding something (I don't normally work on multi-language sites), but isn't it optional to enter page titles in any language other than the default? The user isn't forced to add a title in all enabled languages as far as I can see. So it seems like it's a question of user education more than anything else, the lesson being "only create page titles in languages that you need", which is really part of a more basic general lesson that any CMS user must learn: "only fill out fields that you have information for".

Thanks for the prompt response, that fixes it here.

Hi @adrian, In the Mail Interceptor panel, special characters are scrambled in the From field: I think this might be glitch in the Mail Interceptor panel rather than a WireMail issue because the From value seems to render properly in my email client. But if it isn't a Tracy issue and is actually a WireMail problem I'd want to report it to Ryan. Could you take a look when you have a chance? Thanks.

@Macrura has created a couple of modules for adding help documents to the admin: Myself, I just create a PW page (hidden from non-superusers in the admin) that contains instructions for users. I use some custom jQuery in the admin to append an "Instructions" view link to the admin footer so the document is always easily accessible from any page. To provide some intervention against duplicate pages you could try a hook like this: $pages->addHookAfter('added', function(HookEvent $event) { $page = $event->arguments(0); $pages = $event->object; // For pages with a particular template... if($page->template == 'basic_page') { // Check for existing page with the same title // You could get fancy by making this more fuzzy // E.g. exclude short words and then look for titles that contain the remaining words $existing_page = $pages->get("template=basic_page, title={$page->title}"); if($existing_page->id) { // You could use the edit URL or view URL as appropriate $url = $existing_page->editURL; $event->wire()->warning("There is an existing page with this title <a href='$url' target='_blank'>here</a>. If you have added a duplicate page by mistake please delete this page.", Notice::allowMarkup); } } });

I don't understand what you're saying here or what screenshot you're referring to. But my general point is that fields like Page Reference or Repeater are ultimately about storing a relationship between pages (Repeater items are pages). Rather than use a field to store the relationship, you can use the parent-child relationship. In PW, until pagination support is eventually rolled out to Page-type fields only the parent-child relationship can scale to thousands or millions of pages. But for your case this should be no big problem because the parent-child relationship can achieve what you are doing with the Repeater field. You get a nice sortable paginated list of child pages on the Children tab, and you can customise the page labels in a similar way to the Repeater item labels (see "List of fields to display in the admin Page List" in the Advanced tab of the child template). I would just stick with the Children tab, but if you wanted try more things you could look at Batch Child Editor, or listing child pages using a runtime-only inputfield with modules like this or this, or making use of Lister / Lister Pro to view and filter the child pages.

Personally, I don't allow non-superusers to see the trash and I like that they have to navigate to the Delete tab because I want them to think very carefully before they delete a page. If you want to hide Trash (as per the setting mentioned above) but want to let non-superusers trash pages from Page List then you could look at this module:

FYI, you can disable trash for non-superusers in the ProcessPageList module settings: https://processwire.com/blog/posts/processwire-3.0.107-core-updates/#trash-for-all

I'm not surprised that 1000 repeater items in a field is slow to load. My suggestion is to replace your repeater field with child pages.

I don't know the exact reason why your "TEST<br>" line is output twice, but what you're doing there is not correct usage of Markup Regions. The docs explain that when using Markup Regions you set... $config->appendTemplateFile = '_main.php'; ...so that every template file will append the markup contained in _main.php. And... This means that all the markup that is in a template file will be output before the <html> tag that is in _main.php. Of course that would normally be invalid HTML because no markup should occur before the opening <html> tag. But as the docs explain... So all the markup in a template file should correspond to a matching region that is defined in _main.php, so that when Markup Regions parses the output it can relocate the markup in the template file into the corresponding regions defined in _main.php. If you have markup in a template file that does not correspond to a region in _main.php then Markup Regions is not going to be able to make sense of it, and that is what's happening with your "TEST<br>" line. To confirm you can enable debugging for Markup Regions and it will alert you to problems: https://processwire.com/docs/front-end/output/markup-regions/#debugging-regions

Yes, it's still the same as it was, it's just that in the documentation the getById() method has been replaced with getByIDs() since v3.0.156. See "joinFields" here: https://processwire.com/api/ref/pages/get-by-i-ds/ Example with $pages->find(): $items = $pages->find("template=colour", ['loadOptions' => ['joinFields' => ['headline', 'text_1']]]);

I can confirm the problem. GitHub issue opened here: https://github.com/processwire/processwire-issues/issues/1253

https://processwire.com/docs/fields/select-options-fieldtype/#manipulating-options-on-a-page-from-the-api

It's a bug - please open an issue on GitHub to bring it to Ryan's attention. The URL segments array has a 1-based index but this is lost to a 0-based index when the array is reversed here: https://github.com/processwire/processwire/blob/ee4c46a442f09cf81f9e1800c5fdfcd1176f538a/wire/core/WireInput.php#L576 As a workaround for now you could do this: $segments = $input->urlSegments; $last_segment = end($segments);

I've added a note about the incompatibility with LanguageSupportPageNames to the module readme. I'm not sure how LanguageSupportPageNames works exactly or what part it plays in multi-language functionality but I can see that, like Custom Paths, it hooks Page::path and performs redirects before pages are viewed. This makes me think it may be impossible for these two modules to work together, but if anyone with multi-language experience can see a solution I'd be glad to apply any fix.

v0.1.4 released: this version adds the functionality that if a visitor attempts to view a page at its real path (maybe they have it bookmarked or are following an old link) they are redirected to the custom path.

I can't reproduce that. If I set the custom path to something that it is in PagePathHistory for the page then I can successfully view the page at the custom path without being redirected by PagePathHistory. If you can give me some steps to follow that will consistently reproduce the problem on a clean installation let me know and I'll try and investigate further.

You can't use the PW core image plugin because in FormBuilder there is no page to store images in. But I have just released v0.1.2 which lets you configure a global toolbar for all Markup CKEditor fields. If you add "Image" to the toolbar setting you can use the standard CKEditor image plugin to insert an image by URL.

Welcome to the PW forums @j-w! The thing you're asking about doesn't relate to PW as such - it's more an Apache question. As far as I know there isn't anything in the PW htaccess that would prevent you from using basic auth. I don't think you can use <Location> in htaccess - that has to go in your virtual hosts config file. If you want to use htaccess then this Stack Overflow answer might help (it worked for me when I tested it): https://stackoverflow.com/a/14605066/1036672 Or see the answer to the same question for a virtual hosts example: https://stackoverflow.com/a/26980313/1036672

For anyone interested in how you might do this by modifying the SQL query that's created from a PW selector, here is one way: In your template file or wherever: // A field name is supplied in a custom "empty_first" item in the $options array // The field name supplied here must also be used as a sort value in the selector string $items = $pages->find('template=news_item, sort=-date_1, limit=20', ['empty_first' => 'date_1']); In /site/ready.php: $wire->addHookAfter('PageFinder::getQuery', function(HookEvent $event) { $options = $event->arguments(1); // Return early if there is no "empty_first" item in the $options array if(!isset($options['empty_first'])) return; // Get the DatabaseQuerySelect object /** @var DatabaseQuerySelect $dqs */ $dqs = $event->return; // Prepend a custom ORDER BY $dqs->orderBy("ISNULL(_sort_{$options['empty_first']}.data) DESC", true); // Return the modified query $event->return = $dqs; });

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");

Set the form action to the be the same URL that renders the form. Or just don't set the action for the form because the current URL is the default action. Look for the name of the submit button ("submit" is the default) in $input->post and process the form input when it is present. Example: public function ___execute() { $input = $this->wire('input'); $modules = $this->wire('modules'); /** @var InputfieldForm $form */ $form = $modules->get('InputfieldForm'); /** @var InputfieldText $f */ $f = $modules->get('InputfieldText'); $f->name = 'greeting'; $f->label = 'Greeting'; $form->add($f); /** @var InputfieldText $f */ $f = $modules->get('InputfieldText'); $f->name = 'name'; $f->label = 'Name'; $f->required = true; $form->add($f); /** @var InputfieldSubmit $f */ $s = $modules->get('InputfieldSubmit'); $form->add($s); // Process input if form was submitted if($input->post('submit')) { // Core form processing (required, etc) $form->processInput($input->post); // Custom processing $greeting = $form->getChildByName('greeting'); if($greeting->value !== 'Hello') { $greeting->error('Please say "Hello"'); } // Redirect (Post/Redirect/Get pattern) $this->wire('session')->redirect('./'); } return $form->render(); }

Ryan's comment in the fixed GitHub issue: Therefore, to include unpublished pages you must get the unformatted value of the field: $items = $page->getUnformatted('your_page_reference_field_name');

Could you please show the code you are using to access your custom image fields in your template file, and explain what error/problem happens when you try to do this? I might be misunderstanding but it seems like you are getting hung up on the inputfield names in Page Edit when really you don't have to worry about these. You just access the custom fields from the Pageimage object using the names of the fields that you added to the template. So if you added the "title" field to the template that defines your custom image fields you access that field as $image->title, where $image is the Pageimage object from your image field. The relevant part of the introductory blog post is:

It's partly covered by the icons but it's just the field name: "image"

Are you referring to the input names when you inspect them in your browser dev tools? It's normal for them to have that suffix - I expect it's to distinguish between inputs when there are multiple images in the same Page Edit form. But you should still be able to access the custom image fields without any suffix. It's working for me - see screenshot: