Robin S

After you get the home page you should set its output formatting state to false because you are about to manipulate and save it. $home = wire("pages")->get(1); $home->of(false);

Not a solution, but for an explanation of why querystrings are not retained in automatic redirects see Ryan's comments in these GitHub issues: https://github.com/processwire/processwire-issues/issues/636 https://github.com/processwire/processwire-issues/issues/77 https://github.com/processwire/processwire-issues/issues/1140

@adrian, I have an idea for a different solution to the problem. I'll report back once I've done some work on it.

I did try your suggestion but the default for $config->sessionFingerprint is "10", which means the session fingerprint is going to include the IP from $_SERVER['REMOTE_ADDR']. When WireHttp requests the page this is going to be the server IP and so it's not going to match the IP in the user fingerprint and a logout will occur. Maybe it would be possible to spoof $_SERVER['HTTP_CLIENT_IP'] or $_SERVER['HTTP_X_FORWARDED_FOR'] but this would mean users have to change from the default session fingerprinting setting. @adrian, when you say you got it working did you test yet on a remote server?

Arrgh, I think it's due to session fingerprinting - the WireHttp request is failing Session::isValidSession(). Will try some more experimentation a bit later.

Hmmm, I was testing locally on Windows but I just tested on my Linux remote hosting and it worked there too. PW itself will call session_write_close() at shutdown so I don't think that in itself should cause a logout. Perhaps you have other hooks after ProcessWire::finished that have the effect of starting a new session? Maybe try setting a high number for the hook priority - the idea being that this hook to get the links should be the last thing that runs before shutdown. I just realised that I haven't yet dealt with the HTTPS situation - I've only been testing on HTTP so far. Will report back if/when I can make some progress with HTTPS.

I made some progress! ? The problem is session blocking: a session is already started and not yet closed when Tracy (or any code in a template file, like I was using for testing) attempts to get the response for the link using the same session cookie. So we need to close the existing session before using WireHttp. It wouldn't be good to close the session during the Tracy module config save because it's probably still needed at that point, so I'm using a hook after ProcessWire::finished when it should be safe to close the existing session. I also made some other minor tweaks for efficiency: only processing the links if they have changed from the existing config data, and moving the instantiation of WireHttp outside the foreach loop. I replaced this code with the following: $existingConfig = $this->wire('modules')->getModuleConfigData($this); $existingLinks = isset($existingConfig['linksCode']) ? $existingConfig['linksCode'] : ''; $savedLinks = isset($data['linksCode']) ? $data['linksCode'] : ''; if($savedLinks !== $existingLinks) { $this->addHookAfter('ProcessWire::finished', null, function($event) { // Make URLs in links panel root relative and get titles if not supplied $tracyConfig = $this->wire('modules')->getModuleConfigData($this); // Close existing session to avoid session blocking session_write_close(); $allLinks = array(); $http = new WireHttp(); $http->setHeader('Cookie', "wire={$this->wire('input')->cookie->wire}; wire_challenge={$this->wire('input')->cookie->wire_challenge}"); foreach(explode("\n", $tracyConfig['linksCode']) as $link) { $link_parts = explode('|', $link); $url = trim($link_parts[0]); $title = isset($link_parts[1]) ? trim($link_parts[1]) : ''; $url = str_replace($this->wire('config')->urls->httpRoot, '/', $url); if($title == '') { $fullUrl = strpos($url, 'http') === false ? $this->wire('config')->urls->httpRoot . $url : $url; $html = $http->get($fullUrl); libxml_use_internal_errors(true); $dom = new \DOMDocument(); $dom->loadHTML($html); $list = $dom->getElementsByTagName('title'); libxml_use_internal_errors(false); $title = $list->length ? str_replace('|', ':', $list->item(0)->textContent) : $url; } $finalLink = $url . ' | ' . $title; $allLinks[] = $finalLink; } $tracyConfig['linksCode'] = implode("\n", $allLinks); // Calling saveModuleConfigData with underscores because we don't need hooks to run again $this->wire('modules')->___saveModuleConfigData($this, $tracyConfig); }); }

The symptoms indicate that the click event that is supposed to show the edit pane isn't being triggered as expected. To debug you can use some custom JS to find out what the target is when you click on the thumbnail: $(document).on('click', function(event) { var $target = $(event.target); alert($target.attr('class')); }); On most browsers and devices you'll see: "gridImage__edit", which is what is expected in InputfieldImage.js But when I tested on Android I got: "gridImage_inner" and there is no event handler bound to that element. Why doesn't Android trigger the click event for .gridImage__edit? Perhaps because .gridImage__edit is display:none until the outer .gridImage element is hovered. And it seems that Android is quirky when it comes to triggering events on elements that are not visible, because even if you force display:block on .gridImage__edit and add visibility:hidden or opacity:0 it still won't trigger the click event. What worked for me was forcing display:block on .gridImage__edit and then using display:none on the child span so that the "Edit" label only appears on hover as intended (on devices that support hover or at least emulate it better than Android seems to be able to). So in some custom admin CSS try: .gridImage__edit { display:block !important; } .gridImage__edit span { display:none; } .gridImage__edit:hover span { display:inline; } I couldn't reproduce that on my Android tablet - a single touch worked for me.

@totoff, you might find this new module useful - it lets you easily copy a Markdown file link to the clipboard:

This module is sort of an upgrade to my earlier ImageToMarkdown module, and might be useful to anyone working with Markdown in ProcessWire. Copy Markdown Adds icons to images and files that allow you to copy a Markdown string to the clipboard. When you click the icon a message at the top left of the screen notifies you that the copying has occurred. Screencast Note: in the screencast an EasyMDE inputfield is used to preview the Markdown. It's not required to use EasyMDE - an ordinary textarea field could be used. Usage: Images When you hover on an item in an Images field an asterisk icon appears on the thumbnail. Click the icon to copy an image Markdown string to clipboard. If the "Description" field is populated it is used as the alt text. You can also open the "Variations" modal for an image and click the asterisk icon to copy an image Markdown string for an individual variation. Usage: Files When you hover on an item in a Files field an asterisk icon appears next to the filename. Click the icon to copy a link Markdown string to the clipboard. If the "Description" field is populated it is used as the link text, otherwise the filename is used. https://github.com/Toutouwai/CopyMarkdown https://processwire.com/modules/copy-markdown/

Thanks for sharing this. ? Another possible way to approach this is to use a single Hanna tag for all allergens and then use Hanna Code Dialog to create an interface where a site editor can select allergen types by label. You could use a page per allergen type and use the (multi-language?) title field for the label and an integer field for the allergen number. Then use a hook to set the options for the dialog. $wire->addHookAfter('HannaCodeDialog::buildForm', function(HookEvent $event) { // The Hanna tag that is being opened in the dialog $tag_name = $event->arguments(0); // The form rendered in the dialog /* @var InputfieldForm $form */ $form = $event->return; if($tag_name === 'allergen') { /* @var InputfieldCheckboxes $f */ $f = $event->wire('modules')->InputfieldCheckboxes; $f->name = 'type'; $f->id = 'type'; $f->label = 'Type'; foreach($event->wire()->pages->find("parent=/references/allergens/") as $allergen) { $f->addOption($allergen->allergen_number, $allergen->title); }; $form->add($f); } }); Or maybe if you are using a Repeater for your menu items you don't need Hanna Code and could just use a Page Reference field to select allergen pages per menu item.

@adrian, I've tried but unfortunately I haven't had any success with getting the titles of admin pages. ? I turned off a couple of $config settings while I was testing: $config->sessionFingerprint = 0; $config->sessionChallenge = false; And I used curl directly rather than WireHttp to keep it simple. The problem is that as soon as you set the "wire" cookie value... curl_setopt($ch, CURLOPT_COOKIE, "wire={$input->cookie->wire}"); ...PW just doesn't give any response and curl times out. It doesn't matter if you try and get a PW admin page or a frontend page. I thought it might have been an endless redirect situation but when I get the transfer information with curl_getinfo it looks like no redirects are occurring so it seems that's not the problem. I'd love to know why PW doesn't respond but I don't know how to debug this any further. Unless anyone can make a breakthrough with this maybe it will be a matter of manually setting titles for any links to pages that require a logged-in user. Not a great hardship. ?

Please don't spend a lot of time on this. I'll see if I can work it out in the weekend.

Thanks. The v0.3.0 update to HannaCode is actually a major refactoring of the module so there were a few things in HannaCodeDialog that needed updating for compatibility. The new v0.4.0 of HannaCodeDialog should be compatible with HannaCode v0.3.0 and it requires HannaCode >= v0.3.0.

Awesome, thanks for adding this! The conversion to relative URLs is working great and grabbing the HTML page title is working for external links, but it looks like there's a problem getting the titles of pages in the PW admin. Not sure if there's an easy way to solve that - is it even possible to send WireHttp requests so they appear to come from a logged in superuser rather than guest?

AdminOnSteroids has an option in the PageListTweaks section: "Always show extra actions"

I don't think you're being dim - you're just running up against a necessary limitation of what the AutoTemplateStubs module does. The module is only ever going to operate on files in the AutoTemplateStubs directory that it has created itself. As a matter of safety it's not going to get into the business of modifying/overwriting/deleting files that you have created, such as your custom Page class files. When custom Page classes are not in use AutoTemplateStubs creates stubs for class names like "tpl_basic_page", which don't exist anywhere else in the codebase. They're not "real" classes that do anything - they're just a way to tell the IDE about overloaded properties when you use a PHPDoc comment to (falsely) state that $page is an instance of class tpl_basic_page. But if you are using custom Page classes then two things apply: 1. There are necessarily going to be two different class files using the same class name - the "real" class file that you create, and the "fake" class file that AutoTemplateStubs creates. Your IDE will probably warn you somewhere that there are multiple definitions for the same class name. 2. Your IDE "knows" that $this is your custom Page class, and it's likely to "prefer" what it knows about $this from the custom Page class file over anything that is contained in the AutoTemplateStubs stub file. You can manually copy over the PHPDoc comments from the AutoTemplateStubs stub file to your custom Page class file if you find that's useful, but nothing is going to be kept in sync so you won't be getting the "auto" part of AutoTemplateStubs.

Just checking: you know for certain that you have published, unhidden pages that use template "my-template" as descendants of $page (i.e. you can see them in the page tree) but they are not returned with either: $results = $page->find("template=my-template"); or $results = $pages->find("has_parent=$page, template=my-template"); (both of these are effectively the same thing) If that's the case it's possible that something has gotten messed up in the pages_parents database table. In PW 3.0.156 or newer you can rebuild the pages_parents table by executing the following in the Tracy console or in a template file: $pages->parents()->rebuildAll(); See method PagesParents::rebuildAll()

There is such a method in recent versions of PW: https://github.com/processwire/processwire/blob/d8945198f4a6a60dab23bd0462e8a6285369dcb9/wire/modules/Process/ProcessForgotPassword.module#L992-L1004 Are you maybe running an older version of PW?

Not all the API variables and classes are included in the API Reference menus. For example, the whole $fieldgroups API variable and methods exist in the documentation but do not appear in the menus. Ryan has said: Personally I'd rather have everything listed in the menus. In terms of modules there is also the Pro API Explorer.

A Fieldtype for dynamic options that are generated at runtime via a hook. Configuration Inputfield type You can choose from a range of inputfield types on the Details tab of a Dynamic Options field. Your field will return a string or an array depending on if the selected input field type is for "single item selection" or "multiple item selection". Maximum number of items You can define a maximum number of items the field is allowed to contain. The core inputfields supported by this module will become disabled once the limit is reached. This option is only applicable if you have selected an inputfield type that is for multiple item selection. Format as Pagefile/Pageimage object(s) If the field will store paths/URLs to Pagefiles/Pageimages then you can enable this option to have the formatted value be a Pagefile/Pageimage object for "single" fields or an array of Pagefile/Pageimage objects for "multiple" fields. There is a related Select Images inputfield module that allows you to visually select image thumbnails. Defining selectable options Selectable options for a Dynamic Options field should be set in a FieldtypeDynamicOptions::getSelectableOptions hook in /site/ready.php. The hook should return an array of options as 'value' => 'label'. An example hook is shown on the Details tab of a Dynamic Options field: $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { // The page being edited $page = $event->arguments(0); // The Dynamic Options field $field = $event->arguments(1); if($field->name === 'your_field_name') { $event->return = [ 'red' => 'Red', 'green' => 'Green', 'blue' => 'Blue', ]; } }); Formatted value If a Dynamic Options field uses a "single" input type then its formatted value is a string, and if it uses a "multiple" input type then its formatted value is an array. The unformatted value of a Dynamic Options field is always an array. Also see the Configuration section above for description of an option to have the formatted value be Pagefile/Pageimage object(s). Examples of possible uses $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { // The page being edited $page = $event->arguments(0); // The Dynamic Options field $field = $event->arguments(1); // Select from the "files" field on the page if($field->name === 'select_files') { $options = []; foreach($page->files as $file) { // Value is basename, label is description if one exists $options[$file->basename] = $file->get('description|basename'); } $event->return = $options; } // Select from files in a folder if($field->name === 'select_folder_files') { $options = []; $path = $event->wire()->config->paths->root . 'my-folder/'; $files = $event->wire()->files->find($path); foreach($files as $file) { // Value is full path, label is basename $options[$file] = str_replace($path, '', $file); } $event->return = $options; } // Select from non-system templates if($field->name === 'select_template') { $options = []; foreach($event->wire()->templates as $template) { if($template->flags & Template::flagSystem) continue; $options[$template->id] = $template->name; } $event->return = $options; } // Select from non-system fields if($field->name === 'select_field') { $options = []; foreach($event->wire()->fields as $field) { if($field->flags & Field::flagSystem) continue; $options[$field->id] = $field->name; } $event->return = $options; } // Select from FormBuilder forms if($field->name === 'select_formbuilder_form') { $form_names = $event->wire()->forms->getFormNames(); // Use form names as both keys and values $event->return = array_combine($form_names, $form_names); } }); https://github.com/Toutouwai/FieldtypeDynamicOptions https://processwire.com/modules/fieldtype-dynamic-options/

@CalleRosa40 I use the AddNewChildFirst feature regularly and so can confirm that it works. Check that you have enabled it for the correct template: the template of the pages that will be added at the top, and not the template of the parent page. The configuration is different from Pagetree Add New Childs Reverse in this regard. And I assume you have uninstalled Pagetree Add New Childs Reverse - you wouldn't want to have this module and the AOS feature running at the same time. Edit: I see now you already said that you uninstalled Pagetree Add New Childs Reverse.

No, CKEditor isn't a supported inputfield. I expect it would create rendering issues in the tag if it contains HTML, and if you are putting anything more than a short piece of text in your "read more" it would result in a huge, cumbersome tag widget. Instead I think you should wrap the "read more" text in "open" and "close" Hanna tags. [[rm-open]] <p>Your text here.</p> [[rm-close]] Then replace the [[rm-open]] with a "Read more..." button and a div open tag, and the [[rm-close]] with a div close tag. Use JS to toggle the visibility of the div when the button is clicked. You could also look at TextformatterPagination and TextformatterAccordion for inspiration but I think the above method would be the simplest.

v0.2.5 released. In this release stub files will always be created in and deleted from an "AutoTemplateStubs" directory and you can choose where this directory will be created. This avoids the risk that somebody accidentally configures an existing unrelated directory as the stubs directory. Please update to this new version for safety's sake.

The page name also seems to work: $pages->find('images.tags=the-page-name') And in case it's not obvious, you can also find the page(s) used in the Page Reference field in a separate step and then use that Page/PageArray in the selector because it will be converted to ID(s) when treated as a string. // Find the tags you want to search for $search_tags = $pages->find("template=tag, title=blue|green"); // Find the pages with these tags in the images field $results = $pages->find("images.tags=$search_tags");