BitPoet

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