adrian

Now I feel like I am just hijacking this thread, but another big shout-out, this time to @elabx

And another big thanks to @Pixrael for being number two!

Just wanted to send a big thanks @flydev ?? for being my first Github sponsor!

Thanks @Jan Romero - I am running the latest version from the modules directory, but I see that your fix was implemented since it was last updated - looks like it needs a version number bump here to force an update.

Hi @thetuningspoon - I just noticed this: https://github.com/processwire/processwire-issues/issues/1599 Looks like this module needs to adjust how it inserts itself when a field is Locked. Please let me know if you have any problems reproducing.

Nothing serious - I use it on several sites without any real problems. I guess I just don't really like the inheritance / defaults setup. It's also a shame that Wanze isn't really around here much anymore.

That's not always a bad thing - if it ain't broke, don't fix it :) There is the module by bitpoet that works in reverse (I think - I have used that one, but not this one).

Awesome - thank you! I had forgotten that class_exists tries to load unless you set that optional autoload argument to false. I've made that change so the new version has it. Thanks again.

Ah, yes of course. I like the idea, but the problem is that sometimes it seems like it's possible for Tracy to double load without the composer files, which is why this line was added in the first place. Maybe I need to install nette via composer myself and see if I can reproduce and come up with a better check.

Good point - perhaps I can just remove that second part of the check and leave it as simply: if(class_exists('\Tracy\Debugger')) return; Does that work for you with nette included via composer?

It's still weird to me though because that new line I added should prevent Tracy being loaded a second time. Do you need that composer include, or can you remove it without affecting anything else?

Thanks for looking into it further. I have upgraded several sites on several several servers with no problems so far, so there must be some setting somewhere that's causing the problem. Maybe a Tracy module setting? I fresh install would be a helpful test, thanks.

Hi @dynweb - sorry you're having issues with this newer versions. However, I am struggling to understand why you're seeing that error. Do you see the same problem on other sites / servers? Does a Modules > Refresh help?

The core Page Path History module takes care of these!

@fuzenco - new version just committed that also supports integer & decimal field types as well as float.

Hi @fuzenco - can you please do me a favor and try changing this line: https://github.com/adrianbj/ProcessAdminActions/blob/331e210404b7f883aec04c4342185c04be24d57d/actions/FieldSetOrSearchAndReplace.action.php#L23 to: if (!$field->type instanceof FieldtypeText && !$field->type instanceof FieldtypeFloat) continue; That should work, but please test and let me know and then I'll update the action.

Hi @szabesz - I am heading on vacation tomorrow for a couple of weeks, so it will be a while before I can take a look at this. That said, I am not sure if I can actually do much about this. I actually wonder if this is something that should be raised over at: https://github.com/nette/tracy because I *think* it is something they would be better off fixing in the Tracy core.

Hi @Ivan Gretsky - I am heading on vacation for a couple of weeks as of tomorrow and then of course it will be crazy catching up when I'm back, but thanks for the GH issue. I will try to take a look as soon as I can. Sorry I never got back to it before.

This might be what you're looking for: https://processwire.com/modules/fieldtype-matrix/

Would $pagefile->isTemp() be of use here? https://github.com/processwire/processwire/blob/06325993851113436b20b375a6b08cbf38230657/wire/core/Pagefile.php#L1330 I use it in CustomUploadNames

Looks like it:

And of course it has nothing to do with getPage() either :) Just all about findMany()

I'd recommend you post a Github issue about this for Ryan, in case he doesn't read this thread.

Ok, so I can confirm but it doesn't have anything to do with page classes - it appears to be all about getPage() together with findMany(). Here is a bare bones example with page classes disabled. Notice the change in parent between find and findMany:

That's a real shame - I thought we might have been onto something. I just tested findMany() here, calling that same method I demo'd above and everything looks fine. Does this setup demonstrate the issue when you run it on your site?