BitPoet

I can confirm that behavior here on a pretty clean 3.0.210. Looking at the code, it seems to have been this way for quite some time, so it might even be intended. "Search" shouldn't even be in the menu nowadays, it should be "Find" (and using ProcessPageLister). Did you update that site from an older version?

You should be able to see more details in the browser's developer console telling you why exactly your browser thinks it mustn't display that part. If the messages in the error console don't give you a clue, you should inspect what happens over the network in your developer console. The most likely explanation for that behavior outside of CSP/CORS headers would be that PW for some reason uses a different domain or http vs. https in the request for the form contents in the embedded iframe.

It's not really going to cause issues, more of a visual misbehavior. Starting with version 3.0.190, repeater labels can contain a hexadecimal color value preceded by a hash sign, e.g. #ff0000. Short notation for CSS colors like #ff1 is also supported, so PW interprets item numbers with more than two digits as colors. My guts say this is unintended and could be easily fixed by reordering the code in InputfieldRepeater so the color substitution happens before replacing the counter placeholder, but the change was inititally targeted at the Repeater Matrix Pro fields which I don't have here. Probably best to file a github issue and let Ryan take a look. These are the lines in question: // update index numbers? if($hasCnt) { // replace "#n" with index number of repeater item $repeaterTitle = str_replace("#n", "#$cnt", $repeaterTitle); } if(strpos($repeaterTitle, '#') !== false) { $repeaterTitle = preg_replace('/#([a-f\d]{3,})/i', "$colorPrefix$1", $repeaterTitle); if(strpos($repeaterTitle, $colorPrefix) !== false) $hasColorPrefix = true; }

That's a known issue with PHP 8.2 and already fixed in the dev tree, so it will be in the next stable release. Since this line is the only change in PWPNG.php between 3.0.210 and dev, you could use the file from dev without any side effects. You'll probably hit other PHP 8.2 incompatibilities though (e.g. in MarkupHTMLPurifier), so downgrading to PHP 8.1 might be the easier option.

Just locally, to make sure I'm not missing any cache queries I may not have expected, since I can't just map the database cache's logic to that of a key value store 1:1 while keeping its performance benefits.

For testing reasons, I added the following code after this line to make sure get() is never called in two-argument form. if($func === null) throw new WireExeption('Illegal use of $expiry argument in WireCache::get without a function argument'); So far, I haven't seen any exceptions, even when running maintenance. I'm going to run a lot of tests anyway over the next week as I'm in the process of finalizing my Redis WireCache module. Unless something unexpected pops up there, the docs should probably be amended to read: /** ... * @param int|string|null|false $expire Optionally specify max lifetime (in seconds) OR expiration time as a date string, or false to ignore. * - Do not pass in $expire when calling get() without a $func argument, since the results are likely not what you expect * - If using a $func, the behavior of $expire is the same as that of save(). ... */

$repeaterOwner should be the public page (i.e. 2905), so you now just created a superfluous entry in field_vouchers. You can delete that with 'delete from field_vouchers where pages_id=2906'. What stumps me is that a select on field_vouchers with pages_id 2905 returns an empty result, yet you still get the primary key error. Off the top of my head, I can only think of two scenarios where this could happen (a) your table's index got corrupted somehow, or (b) you're using InnoDB and there's an open transaction that should have inserted the row in question but hasn't sent a commit yet. To be on the safe side, you should probably export your repeater items and for-page-2905 using PagesExportImport and store that. This lets you recreate your repeater pages with identical ids even if PW decides to throw them away at some point. Afterwards, you can try running the SQL query 'check table field_vouchers' and see if the result shows any errors.

Oh, sorry. I've gotten turned around a bit here without noticing it. I must have looked too long at this line when I assembled the sql query: $vv = wire('pages')->find('parent=2906, template=230, sort=sort, include=all'); The sql query with "2906" I had you do was wrong then and should have been 'select * from field_vouchers where pages_id=2905'. Can you run that again? Since there's still data there, let's take a look at what that is before I jump to conclusions (supposedly empty, but who knows, since it shouldn't have gotten into this state at all).

That's okay. I just wanted to be sure that it's actually empty and not filled with incorrect data. Since the pages still exists, this little snipped should do the trick: if($user->isSuperuser()) { $repeaterParent = $pages->get('/admin/repeaters/for-field-513/for-page-2905/'); $repeaterOwner = 2905; $sth = $database->prepare( 'insert into field_voucher ' . '(pages_id, data, count, parent_id) ' . 'values ' . '(:page, :repeaters, :count, :repparent)' ); $params = [ ':page' => $repeaterOwner, ':repeaters' => $repeaterParent->children()->implode(',', 'id'), ':count' => $repeaterParent->children()->count(), ':repparent' => $repeaterParent ]; $sth->execute($params); echo "<pre>Inserted repeater</pre>"; }

Can you take a look into the database and do a "select * from field_vouchers where pages_id=2906"?

Just to understand right, the repeater field is no longer on the template of your main page, right? (If it isn't, don't add it yet!)

It does, but it's usually discouraged, since it raises complexity from O(1) to O(n). I guess as long as the asterisk is added at the end, it might be tolerable in that one instance. I've added a special check for FileCompiler there. I guess it depends on the exact application. If I think of high-load systems with large pages consisting of complex calculations, the benefit in the frontend would mostly still be there, with the biggest workload being (usually) performed in the backend. I'll add both MySQL and Redis implementations anyway to see how they compare. Great, that's going to make things infinitely easier. Thank you!

If you mean in the image picker, you can try out the latest dev version here: https://github.com/BitPoet/MediaLibrary/archive/refs/heads/dev.zip

How would the two caches ever match up? You'd have to write your data to both caches at once, which means you'd end up with slow writes anyway. If you want to use two different caches at the same time for different kinds of data / different areas of the site where one or the other provides real benefits, you can instantiate another WireCache with PW's built-in database engine manually. Assuming you have WireCacheFilesystem installed, you could still do: <?php namespace ProcessWire; /* You can put that block in site/ready.php to make $dbCache available everywhere: */ $dbCache = new WireCache(); $dbCache->setCacheModule(new WireCacheDatabase()); wire('dbCache', $dbCache); /* End of site/ready.php */ // Template code: store a value in the database cache that often gets written but seldom read: $dbCache->save('testentry1', 'This is saved to the database', 3600); ... echo $dbCache->get('testentry1'); // Template code: store a value in the filesystem using PW's default engine that gets read // a lot more often than it is written: $cache->save('testentry2', 'This is saved in the filesystem', 3600); ... echo $cache->get('testentry2');

I've started implementing my find() and save() methods, and most code is just working around specific selectors by WireCache's built-in maintenance routine to keep my caches consistent. Would it be possible to add a maintenance() method to WireCacheInterface? This could simply return "false" to let WireCache continue using its maintenance logic, or true if maintenance has been dealt with by the cacher instance.

Thank you for the detailed explanation! Knowing that some features aren't really used (or at least not in depth) in the core make it appear less daunting. Handling expireNever/expireReserved for saving is pretty straight forward, since it's what Redis does anyway if no expiry is given. I'll still need to mull over searching and selectors for a bit since a straight forward implementation wouldn't even carry a searchable property - it's really just "cache name" -> "cache value". Storing selectors / template ids will need some kind of helper entries (I'm actually doing that in CacheRedis already but I'm not really happy about it). Or it might even make sense to store expiration selectors / templates and their associated cache names in the MySQL database and just retrieve the cached values themselves from Redis (just thinking aloud here). In any case, I'll give it a try and see if I encounter any stumbling blocks.

About that: I'm itching (as far as time allows) to turn CacheRedis into a WireCacheInterface compatible module, but there might be a few stumbling blocks. I see that your modules support searching by expiry, which is not something most key-value-stores are designed for since they take care of expiry on their own. It's okay and possible to read the expiration value for an individual key, though, so I'm not completely sure yet how much of an impact a lack of that is going to have, and which applications besides maintenance are affected. More of a headache will be handling expiration constants like WireCache::expireNever, WireCache::expireReserved etc. since they hold dates in the past, meaning entries with those would expire the moment they are written. My gut feeling tells me that a lot more refactoring in WireCache will be necessary to decouple most of the expiration logic from the cacher implementation, but it might be possible to handle most cases by intercepting those values and applying a different logic. Not sure if I'll find time this (long, here in Germany) weekend to take a closer look. Have a great weekend as well!

It's pretty easy to implement that without a module. Create a page reference field and add it to all applicable templates. Let's call it 'redirect_page'. In your prepend template file, add a little snippet of code that checks if redirect_page is set and issues the redirect if it is. <?php if($page->redirect_page) $session->redirect($page->redirect_page->url);

That's (very) unfortunately not possible because the input field used there, InputfieldTextTags, uses jQuery's selectize addon, which doesn't allow duplicates. A bug requesting that capability has been opened ten years ago. It might help to upvote this bug, then @ryan could adapt InputfieldTextTags (or rework, most likely, since it uses tag values as keys, which also eliminates duplicate values). There's, however, already code inside InputfieldTinyMCEConfigs.php for a textarea instead of a text tags input (with all the downsides of not validating the names entered) for the toolbar config. Just uncomment the code here and comment out the field definition after that.

Check phpinfo for ini setting opcache.restrict_api. AdminLinksInFrontend tries to use opcache for performance. The warning means that there's a path in that setting that doesn't match with the path to AdminLinksInFrontend.module. The module tries to call opcache_get_status() in that line, which triggers the warning. Putting the line ini_set('opcache.restrict_api', '/usr/www/users/floreng/000'); or ini_set('opcache.restrict_api', ''); into site/config.php might be enough to get rid of the warning.

The quickest way would be to add a Page Edit Bookmark for your settings page. Note that the "Edit" menu item is only visible in the Pages menu after you tick the "Allow use of bookmarks" checkbox in ProcessPageEdit's module settings.

Since Latte is a composer package, I'd assume you should require_once '../modules/RockFrontend/vendor/autoload.php' to make sure all dependencies of Latte\Engine are included as well.

Looks like a perfect application for LazyCron. A quick and dirty snippet of code you can place in site/ready.php (or inside a template's PHP file, just make sure that a page with that template is viewed regularly): <?php namespace ProcessWire; // Add daily hook to clean up incomplete, stale pages wire()->addHook('LazyCron::everyDay', null, function(HookEvent $event) { $ts = time() - 86400; // 24 hours ago // Find matching pages, adapt selector however you want (e.g. limit to certain templates or parents) $stalePages = $pages->find("created<$ts, title=''"); foreach($stalePages as $stalePage) { $pages->trash($stalePage); } });

This is because Page Autocomplete doesn't use InputfieldPage::getSelectablePages. Instead, it sends a live query to ProcessPageSearch. Unfortunately, this means that the field settings are written to the JS config, and support for selectors is somewhat limited there. There's been a github issue around for some time with a workaround, which unfortunately means adding a few lines to a core js file, so it needs to be reapplied after every update: https://github.com/processwire/processwire-issues/issues/1374#issuecomment-835032978

Glad to hear my suggestion works. Don't bother about that text in notifications. It's part of a default mail template, but the option to mark solutions isn't enabled in the forum.