adrian

Sorry @teppo - another question / request for you - what do you think about being able to store theme folders in /site/templates/SearchEngine/themes to avoid any issues with overwriting during updates, and also so it's cleaner for version control?

Sorry if I'm being dumb, but when I went to set the 'form_action' argument, I assumed it needed to be an element within the 'render_args' array, but if I do that, it doesn't work. It does work if I set it at the top level of the args/options array that I am passing to the renderForm() method though. If I dump $args without setting this, I see it is at the top level. Did you change something intentionally since writing the docs, or am I just confused ?

Weird thing is that I don't think I have seen those errors in Tracy which uses getQuery() and getDebugQuery() https://github.com/adrianbj/TracyDebugger/blob/116324264c3d566c1cece8c53cc3a1075ca82862/panels/DebugModePanel.php#L232-L239

Sorry about that - I was running 3.0.171. I just updated to 3.0.172 and still seeing the notice, but now it's on line 1493

Hi @teppo - just playing around with this for the first time and got this error when using the Debug Query feature. Not sure if it's an issue with the way you are calling the PageFinderClass? PHP Notice: Undefined index: returnAllCols in .../public_html/wire/core/PageFinder.php:1460

It's something I built for my own use. I am constantly creating new / modified versions of it for all sorts of imports. Here is a copy of what I am currently using for that version: Obviously you'll need to make a lot of changes to have anything useful to you, but it's a good starting point. Also note that I am making use of this CSV library: https://github.com/parsecsv/parsecsv-for-php so you'll need to grab that so it can be included.

Sorry for the delay @lpa - the latest version will now let you replace with an empty value.

Just make use of the $page variable like: "template=item, parent!=$page" Note the double quotes, or if you prefer: 'template=item, parent!='.$page

@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>