BitPoet

It should be $config->paths->assets, not $urls->assets, since you're passing a storage path on the server as the destination path, not a web link. Your code doesn't inspect $img1->getErrors(), even though the comment mentions it before checking $imgs.

Not sure if there's a way to include it directly, but FEEL creates links that open the page editor in a lightbox and reloads the page after saving. You can invoke it with mode = "page-add" to create new pages. If you have the FormBuilder pro module, you can create forms that are saved directly to pages and use most of the input fields available in the backend.

You could create a template and page to output the settings page image and specify that URL in the theme setting. Simplification: if your settings page doesn't have a PHP template yet, you could use that one, or you could extend the existing one. With url segments, you could even pull different stuff from it (logo image, icons, disclaimer, ...). Code for settings template: <?php namespace ProcessWire; if($input->urlSegment(1) === 'logo') { wireSendFile($page->logoimage->filename, [ 'exit' => true ]); } Then just put /path/to/settings/page/logo/ into the logo image file field.

The question is: is $event->return already null when your hook is entered? If yes, the problem happens earlier.

The quickest way would be to hook $page->editable($field). An raw example for site/ready.php, you'd have to extend it to match your role/templates/fields: wire()->addHookAfter("Page::editable", function(HookEvent $event) { if(!$event->return) return; $fieldName = $event->arguments(0); if(!$fieldName) return; $page = $event->object; if(! $event->user->hasRole('your-limited-editor-role')) return; if($page->template->name !== 'your-editable-template') $event->return = false; if($fieldName !== 'your-editable-field') $event->return = false; });

Shouldn't the cart belong to $session or $user? You could of course make $cart a static property in your WebshopPage class to have a singleton of Cart and only instantiate it if it is still null.

It's expected behavior as the selector in a conditional hook is applied to the event's object, which in this case is $pages, not the page that is about to be saved. You can convince PW to match the selector against the hook's arguments by stating the argument's number in front of the selector (there's an example in the docs towards the end of the conditional hooks section). In your case for the first argument, which contains the page: // match selector against $event->arguments(0) instead of $event->object: $this->addHookAfter('Pages(0:template=repeater_gallery)::saveReady', $this, 'myHook');

Seems more like an open_basedir restriction to me than allow_url_fopen.

Do you have the old site still running somewhere? If yes, this query should give you the schema and table with the offending column (if it's in fact a column with that name and not some other issue with SQL syntax): select * from INFORMATION_SCHEMA.columns WHERE column_name = 'index';

Thanks! I added my proposed solution to the issue.

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.