adrian

@lpa - BCE only supports one level of importing. If you're importing content along with the second level pages, then you'll need to create the first pages first, but if you're just trying to create a hierarchy of pages with titles only for now, then this might help: https://processwire.com/modules/admin-actions-unordered-list-to-pages/ Otherwise, I tend to do all my complex imports these days with a custom AdminActions action. This is great if you have a complex CSV export from an old site - not sure if this is what you are doing or not, but just in case: I find this approach really useful as I can quickly do test imports and continue to tweak until I have everything correct. It even allows importing specific items from the CSV (by ID, or some other field if you want). You can then easily remove all test imports and do a full import of everything.

You gotta thank @Robin S for the idea and implementation of those: https://processwire.com/talk/topic/24932-feature-requests/?do=findComment&comment=210091

v4.21.42 fixes an issue in the last version where the debug bar wasn't showing.

@MoritzLost - should be fixed in the latest version 4.21.42 Please let me know if you still have any problems.

Yeah, I think I figured it out - it's to do with that new restricted superuser setting. I'll work on a fix shortly, but if you add a new "tracy-debugger" user permission to the system, it should work again.

Hi @MoritzLost - sorry about this. I have copied your settings and can't reproduce the issue - I think it might be related to the new "restrict superusers" option I added for Pete, but can you please let me know if you are running this site on a local dev environment or remote server? Also, does checking "force superuser into development mode" fix it?

In addition to the thread that @teppo linked to, also take a look at: https://github.com/adrianbj/TracyDebugger/issues/32 Not sure why Valet hasn't fixed it yet though.

Hi all, I won't always post here when I update Tracy, but I will when I think the update is an important bug fix that you really should update to. There was a bug in the new 2.8 branch of core Tracy package that was sometimes causing recursion and really slow load times and sometimes memory exceeding errors. This has been fixed and is available in 4.21.41 of Tracy released today.

@Pete - your "allowed superuser" option is now available in the latest version. @Robin S - I implemented your quicklinks filtering - I think it's a really nice improvements - thanks! Also, I haven't forgotten about your shortcut links panel idea - it's next on my list.

I think this might finally be properly fixed, but please let me know if you still see issues.

Sorry for the delay guys - the latest version hacks back in the file / line number so that both the bd() call and the file/line is visible. Let me know if you find any layout issues.

Yes, I assumed it would check the template of each page to be returned and only autoload those relevant fields. Right, but there wouldn't be any downside either, would there? It's a good point of course. I suppose the autojoin would be more useful for example on a blog parent page (showing featured image, title, author, tags, date, summary etc) for the latest 10 posts, rather than an individual blog page showing all those fields plus the full body content.

@ryan - this sounds like another awesome update! Admittedly I haven't played with this new version yet, but my initial thought after reading the blog post is whether we could have a: $pages->find("$selector, field=all"); as a complement to: $pages->find("$selector, field=none"); For many pages/templates, I always need to access all fields on every load and this would make it much simpler than listing out all the fields separately. Does that sound like a useful addition?

Perhaps, but I would play around with it - you'll find many of its other features invaluable ?

Try @tpr's essential AdminOnSteroids module which packages everything needed for this to work.

In PHP 8.0 the deprecation notice is converted into a parse error: If short_open_tag is enabled, the use of <? is a parse error. If short_open_tag is disabled, <? has no special meaning (as before). In PHP 9.0 support for short_open_tag is dropped entirely: <? never has special meaning, it is always interpreted as plain text. This deprecation and removal plan avoids unintentional code leaks during PHP version upgrades. https://wiki.php.net/rfc/deprecate_php_short_tags_v2 As for echo vs print - I am not suggesting one over the other - just that you shouldn't use either in a <? shorttag because it won't be available soon. <?= is still OK though. As for the whitespace, here is a test I just tried: Now, I do see a whitespace character after the "11111" but that is after the </p> I don't see any whitespace where it shouldn't be. Perhaps you can do a similar test with screenshots to show us what you are seeing.

What type of field is "something"? I am not seeing any whitespace issue here with a text field. Also, that code as you have it is a bit weird and might not actually work at all on some systems. You either want the opening php tag to be: <?php or, you want to use like this: <p><?=$page->something?></p>

I actually have a new version in the works that allows restricting Tracy completely from specific superusers - trouble is I've been really busy with client work and haven't managed to get it released yet. I also have other changes partially complete. I think for the moment, grab the version I posted for Pete: https://processwire.com/talk/topic/24932-feature-requests/?do=findComment&comment=210040 which will let you prevent your other superusers from messing with things. Keep in mind of course that as a superuser, they could still adjust their permissions to get around this limitation, but I expect that like Pete you're really just trying to make sure they don't do things accidentally, rather than maliciously. Let me know how that version goes for you - it would be good to get someone else testing before I release it.

Hi @Ivan Gretsky - glad you're enjoying it! Not really sure what you mean by "safe". Are you worried that non-authorized users may have access to use it? There are no issues there. Otherwise, it's only as safe or dangerous as the code you run.

Not sure that I have ever tested to be sure, but it sounds like the problem is because the field is set to be "required". That said, I feel like it might be useful to be able to reset even required fields to empty values using this action so I might have to take a deeper look.

Glad you found the problem - modules and other hooks are usually the cause of weirdnesses like this. FYI - recent versions of PW have the built in ability to force unique email addresses so no need for that hook.

Do you mean uninstall rather than disable? And is BD meant to be DB (database)? Also, what is stopping you from disabling or uninstalling - do you get an error message or just nothing happens? I feel like there has to be something strange about this installation if you are running the same versions of everything on others and it's working fine.

It only lists modules that are autoloaded which should be all you need to worry about and it's also all that the PW supports disabling.

It's not if you use Tracy's Module Disabler panel like I suggested above ?