BillH

After some experimentation, here's what I'm now using to get the relevant pages: $startDate = strtotime("-2 months"); // Use RockFinder to get recently saved pages with images $recentPagesWithImagesSelector = "has_parent=/articles/,article_images.count>0,modified>{$startDate},include=unpublished,sort=-modified"; $finderRPWI = new RockFinder($recentPagesWithImagesSelector,['title']); $recentPagesWithImages = $finderRPWI->getPages(); // Use standard PW find to reduce to pages with at least one recent image $pagesWithRecentImages = $recentPagesWithImages->find("article_images.created>{$startDate}"); No doubt this could be improved (e.g. by maintaining an index of recent images), but it reduces the page-loading time to something acceptable. Note that I tried a one-step process using RockFinder only with "article_images.created>{$startDate}" in the selector, but this produced a few unexpected results, and anyway was slower than the above. I didn't investigate what was happening in any depth. I have also used RockFinder in another place on the page where a search was running slowly, and the page is now loading more quickly than before I added the list of images!

Thanks @Zeka, that makes a big difference, reducing the time taken to less than half of what is was previously. And thanks also @Autofahrn, that sounds a really interesting approach to improving performance further. The system is already quite well established, so I probably can't switch to having each image on a page (or at least not easily), but some variation on your idea might work well. For example, hooking on image load and storing relevant data (such as the time of the most recent image load) in a field on the page or some similar approach might work. And @Zeka, the SQL and RockFinder ideas seem interesting too. I now need to close down for the day, but I'll look into all these further over the next day or so.

I'm using the following code to get an array of recently added images with various bits of information about them, sorted in reverse order of when they were added. $startDate = strtotime("-2 months"); $pagesWithRecentImages = $pages->find("article_images.created>{$startDate},include=unpublished"); $recentImages = array(); foreach($pagesWithRecentImages as $pwri) { foreach($pwri->article_images as $image) { if ($image->created >= $startDate) { $sortKey = $image->created; $recentImages[$sortKey] = array($image->page->title, $image->page->url, $image->basename, $image->created); } } } krsort($recentImages); It works fine, and I'm displaying the contents of the array on a dashboard page on the admin side. However, it runs rather slowly, delaying the loading of the dashboard page by a few seconds (around six or seven seconds when getting images from about 5,000 pages). The page already takes 3 or 4 seconds to load (it shows other stuff too), and a total of ten seconds or so is a bit frustrating for users. I've been trying to work out a faster way of getting an array of images (perhaps using different selector), but so far with no success. Can anyone think of a way to get it to run more quickly? Thanks!

The issue that I raised on May 8 has now gone away. It was very probably caused by an entirely separate problem I was having with permissions, and thus is nothing to do with this module! I posted about the permissions issue at https://processwire.com/talk/topic/19266-page-edit-permission-not-working/.

Strangely, the problem has gone away all by itself! Obviously this is a good thing for the project, but it means that I don't know the cause of the trouble and can't offer a solution. The only thing I can think of that I changed and that might have affected permissions in some way - though this is a total guess - is that I discovered an image field which, for no reason I'm aware of, had access control enabled (I may have accidentally clicked something or done something through the API). It's possible, though I can't think why, that disabling this access control triggered the resolution of the issue. If anyone else comes across this problem, it'd be interesting to know how they fix it.

Thanks, Robin S, these look like really useful suggestions. I've certainly tried suggestion 3 already (many times!), but I'll get on with 1, 2 and 4. I'll report back.

I'm still completely stuck on this and have tried everything I can think of - including moving the system to a new database (in the same way as I would if moving to a new server). Does anyone have any clues at all? The horrible prospect of many days rebuilding the system from scratch is looming, so any help gratefully received!

I feel as if I must be missing something really massively obvious, but the page-edit permission has stopped working, except for superusers. For non-superusers with page-edit permission, the Edit button is not appearing on page listings. And if I go directly to a page's URL (e.g. ...page/edit/?id=123) there's the error message "ProcessWire: You don't have access to edit". Note that Edit Pages access is given on the template pages, so that's not the cause of the problem. There was no problem until recently. Unfortunately, I'm not quite sure when this issue started, as I've been working on the site as a superuser, and noticed only when testing as a non-superuser. Thus it's difficult to work out what might have triggered the issue. I have tried turning permissions on and off, creating new roles and users, clearing caches, removing and adding Edit Pages access to templates, and turning off any modules that I suspect might interfere with permissions (though I'm not sure any actually would). Any ideas for what to try next?

@Robin S Thanks for the advice on debugging. I'd never noticed the $log stuff in PW before, and have been wondering whether the Tracey Debugger module might be a good idea. I've tried every bit of cache clearing I could think of, but perhaps there's something about CKEditor I missed I'll investigate further and report back.

The bug seems to have returned. It's the same as before: the module doesn't work (the menu shows "No files for this page") if the user is not logged in as superuser. I'm using the latest version of the the module, 0.1.5. (And I'm getting the same problem with my own variants of the module.) I thought the issue might be caused changing to PW 3.0.98, but reverting to 3.0.96 and 3.0.62 doesn't help. In the browser, the Console isn't returning any errors, and there's nothing I recognize as relevant under Network. Something must have changed, but can't think what. In fact, not much (that I can remember) has changed on the back end of the site at all in the last week or so. I'm a bit stumped on what to try next!

Excellent. All works fine now. Thanks @Robin S. B.t.w., if anyone is reading this thread, ignore the remarks in my first post about different browsers. I was just getting in a muddle with how I was logged in with each :-( Also worth noting is that CKEditor Link Files works in a really neat way and is great for adapting if you want to insert PW content into CKEditor text. I've actually built a couple of modules based on it, and have one or two more in mind!

Thanks for getting back to me. I'll have a go with the changes this afternoon.

I've created a module based almost entirely on this module, and my problem occurs both with my new module and the original. So even though CKE Insert Links has been incorporated into AOS, this seems the best place to post. My new module allows users to insert links from a list of page names. It is little more than the original module with some renaming of functions and variables, and getting a list of pages rather than a list of attached files; then the menu is displayed in a CKE dialog rather than from the toolbar. My new module and CKE Insert Links work fine in Firefox for all users, and work in Chrome for superusers. But they fail in Chrome (and Edge on early testing) if the user is not a superuser. The failure manifests itself with CKE Insert Links as the menu showing "No files for this page", and in my module with the equivalent error message. I have debugged as far as finding that the problem seems to be with the $.getJSON() function in plugin.js, which is failing to return anything. In the code below, if(data.length) is evaluating to false. Note that the new code is very close to the original module, with functions and variables renamed. function addReferencesDialogMenu(page_id) { // Adds data for dialog menu to DOM $('#link-references-dialog').remove(); var ajax_url = config.urls.admin + 'module/edit?name=CkeLinkRefsDialog&pid=' + page_id; var $list = $('<ul></ul>'); $.getJSON(ajax_url).done(function(data) { if(data.length) { $.each(data, function(index, value) { $list.append( $('<li title="' + value.description + '">' + value.insertionvalues + '</li>') ); }); } else { $list.append( $('<li title="' + config.CkeLinkRefsDialog.no_references_text + '">' + config.CkeLinkRefsDialog.no_references_text + '</li>') ); //$list.append( $('<li class="no-references" title="' + config.CkeLinkRefsDialog.no_references_text + '">NO DATA</li>') ); } }); $('body').append( $('<div id="link-references-dialog"></div>').append($list) ); } The AJAX response section of the .module file is as follows. Again, just like the original, except the middle section that gets page info instead of attached-file info. public function ajaxResponse(HookEvent $event) { // Must be AJAX request, must be for this module, must include pid GET variable if(!$this->config->ajax || $this->input->get->name !== $this->className() || !$this->input->get->pid) return; $page = $this->pages->get( (int) $this->input->get->pid ); if(!$page->editable) return; $event->replace = true; $event->cancelHooks = true; $result = array(); // Get all relevant pages $referencePages = wire('pages')->find('template=reference'); // Build array of page info for menu foreach($referencePages as $refPage) { $pageUrl = $refPage->url; $pageTitle = $refPage->title; $pageTitleArr = explode("|", str_replace("). ",")|",$pageTitle)); $result[] = array( 'description'=> $this->truncate($pageTitle, 60), 'insertionvalues' => $pageTitleArr[0]."|".$pageUrl ); } $event->return = json_encode($result); } I am unable to understand how or why superuser permissions (or absence of such permissions) have any effect. Any help gratefully received!

A good point @kongondo. There should be enough relevant words in the posts to bring it up in a search. And thanks @Robin S. I suspected there wasn't a way to automate CK Editor changes from the API, but there might have been something I hadn't cottoned on to. Using a PHP DOM parser is a good suggestion - though in this case there were only a couple of dozen instances, so I fixed them the "hard" way, editing by hand in phpMyAdmin! Also, thanks for the good advice on formatting species names in titles. I particularly like the reverse-markdown idea, and I've already thought of somewhere I might use it. There's another solution I'm using on another more-complex site, where I'm developing a module that allows users to enter italicized scientific names in a rich text field (the italicization is quite complex because it's botanical names with hybrids and cultivars) and hooks into page saving to keep a plain-text title and the page name up to date. But I have to be a bit careful with the module not doing unexpected things (though it's becoming quite robust), so it's not really worth installing for the simpler case at hand.

A good thought about text formatters @BitPoet, which I followed up, but they turn out not to be the cause of the problem. However, I searched the raw data for the field in MySQL, and there, for some of the records in title_formatted, was the troublesome data. It is old tags from the previous version of the site from which the data was imported. For example, viewed through phpMyAdmin, the title_formatted field for a record contains: <a href="/site/en/tree-info/-407--i-quercus-rubra-i/"> <i>Quercus rubra</i> </a> However, in PW clicking on the Source button for title_formatted gives: <p><em>Quercus rubra</em></p> And more-or-less the same with the browser's Inspect Element tool. So, PW templates are getting the data as it is stored in the database field. But CK Editor is rendering it differently in the PW back end. The data was imported directly by script, and thus was not entered through CK Editor. When the page is opened in the PW back end and saved, the data is stored in the database as it rendered by CK Editor (so in my particular case the extra <a> tags are removed). However, using $page->save() from a script does not trigger the CK Editor behaviour (perhaps there's a way that it could). I'm wondering if it's worth re-posting this information under another title, as it really has nothing to do with finding pages and might be useful for someone.