Robin S

Yep, a pro module from Ryan himself: https://processwire.com/store/login-register-pro/

@ryan, maybe this update needs to automatically trigger a modules refresh? Because when trying to use InputfieldTextTags (in a module config) the assets URLs were wrong: In the line in InputfieldTextTags::renderReady()... $url = $config->urls($this->className()); ...$url was null. Doing Modules > Refresh fixed the problem.

Sounds like a problem with backing up the database rather than the version you are trying to update to. Are you able to do a manual database backup (via ProcessDatabaseBackups) or do you get the same CPU issue? I recently had an issue with database backups but it was causing a memory issue rather than CPU. Turned out it was due to having SessionHandlerDB installed and the sessions were never getting deleted, resulting in a massive sessions table as described in this topic (along with the fix): Unless you have SessionHandlerDB installed this won't be the problem in your case, but it would still be good to check your database in PhpMyAdmin or Adminer to see if there are any very large tables that could be taxing the CPU during a backup.

@PWaddict, when you change the bookmark in the module config, save, and then check the Lister results, are you doing this each time via the flyout menu? In case it's not obvious, the settings for a bookmark are communicated to the Lister via the bookmark URL. The selector and columns are encoded into the "bm" parameter: When you change a bookmark and save the module config the link in the bookmarks flyout menu changes to use the updated "bm" parameter. This means that if you navigated to the module config from a previous bookmark you can't use the browser back button to see the updated bookmark results in the Lister because you'll be returning to the old URL. Likewise, you can't have the Lister open in one tab and change the bookmark settings in another tab and then just refresh the Lister tab. If this doesn't solve your issue I'll need to get some steps to follow for a test case that will let me reproduce the issue.

There's no overhead to pages that is worth worrying about. In my opinion Page Reference fields are a better choice than Select Options fields in 90% of cases - they're more powerful, flexible and future-proof. They're very easy to set up thanks to @adrian's wonderful Page Field Select Creator module. And they do what you're wanting out of the box - via the core "Allow new pages to be created from field?" setting, or via Page Field Edit Links if your referenced pages evolve to contain multiple fields and you want to fill those out as new pages/options are created.

I can't reproduce that. Please explain in more detail.

In v0.1.2 I've added support for columns to be saved in bookmarks. See the updated readme for details, and the screenshot for how you can easily copy/paste a bookmark string from the bottom of the Lister Selector results. Are you able to do this in the core Lister or Lister Pro? This module uses Lister/ListerPro internally and doesn't do anything different with the results section. So maybe a question for the general forum or Lister Pro board rather than for this module thread.

@MarkE, if you are sorting when getting pages from the database (as opposed to sorting a PageArray in memory) you can only sort by properties that have a corresponding column in the database. By default PW doesn't store paths for each page in the database, which is why you can't sort by path. But if you install the core PagePaths module then PW will store paths in the database and so I think you should then be able to sort by path. Another way to do this when you have two levels of pages in your results is to do "sort=parent.sort, sort=sort".

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.