adrian

What about the "Active" column in BCE's edit mode - you should be able to activate the current language (selected in your profile) for all pages at once with this. Another option is the "Page Active Languages Batcher" in the AdminActions module, which lets you enable or disable active status of multiple languages on multiple pages at once.

@MilenKo - I don't think that error has anything to do with Migrator. Please google this for the access issue: site:processwire.com "Selected homepage template cannot be used because it does not define access" Once that is sorted, I think everything else should work fine. I have only ever imported WP posts into a subpage, like "blog", but importing into home should also be fine. Append vs Replace/Overwrite should both work fine, but if you are importing to a new install, I would go with append. I would suggest reducing your xml to just a few posts while you try different things - just so each test is much faster. BTW, I have never needed to change the post type for normal WP blog post type pages - they just worked as is. Late here, so won't be able to respond again until tomorrow, so good luck!

Migrator and MigratorWordpress were written for 2.x so that might be safer, but I have used Migrator itself with 3.x without any issues, but I haven't used MigratorWordpress with 3.x yet. FYI - as I mention above:

Hi @MilenKo - please grab the Migrator version referenced in this Issue and everything should work perfectly https://github.com/adrianbj/ProcessMigrator/issues/4 PS - regarding the WP shortcode issue - there is a setting in MigratorWordpress for converting WP shortcodes to PW hanna code format.

If anything it appears that SessionHandlerDB makes it worse, at least based on my limited testing.

Awesome @Robin S - thanks for the testing. If I gather correctly, it seems like that column type change has fixed everything which is great. Yes, you are right, Tracy stores the html for all the panels in the session and it can get quite large, especially with all the field object info I have in the PW Info panel. Glad this was an easy fix in the end

I'd like to know more about this one - that is the list of panels to show - would you mind debugging the value of that please - I have never seen an issue there. Thanks very much!

So I just tested on a PW 2.7 install and I did see your forged error, but it was to do with the Sessions DB table. If you change the "data" field from "text" to "mediumtext", it should fix things. Ryan made that change for me in PW 3 a while ago, but of course it's still an issue with 2.7. Please let me know if that fixes everything when running the Tracy Master branch.

Thanks for the extra info. I have been working to eliminate all the SessionHandlerDB issues - it's been a total PITA. As far as I can tell in PW 3.x the only remaining issue is that the redirect debug bar doesn't show. The normal and AJAX ones work. I haven't tested thoroughly with 2.7 in quite a while. I have been PM'ing with Ryan regarding the redirect bar and it turns out that I do have a solution by modifying Session::redirect (https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/core/Session.php#L926-L959) to move the header() call to the top of function. Ryan said it used to be that way, but some servers had some issues. I suggested it might be due to the server's "ignore_user_abort" setting, but I am waiting to hear his thoughts on that. Sorry, that was probably more detail than you wanted. The upshot though is that I am wondering if that change to Session::redirect might also fix the issue you are having. The other possibility might be this line (https://github.com/adrianbj/TracyDebugger/blob/b3750ee32fd7e5cdf14dc9e58a18ec2ffaab0b01/TracyDebugger.module#L1105) - does removing that help? It's there for other SessionHandlerDB issues, but it can be removed if Session::redirect is modified as mentioned. Back to the differences between Master (2.4) and Legacy (2.3) of the Tracy core - the primary advantage to Master is the addition of the AJAX bar. You'll actually find the rendering of the debug bar in the Legacy version much faster - I have an issue (https://github.com/nette/tracy/issues/247) posted about this, but not sure much can be done to fix given the way the master version works. Not sure if that helps or if you feel like investigating any of those tweaks. I don't want to put much more effort into this until I hear back from Ryan because I am already beyond frustrated with the issues with the SessionHandlerDB module, and from what I can tell it is currently pretty good with PW 3.x. Cheers, Adrian

Hi @Robin S - just to clarify - the only "form" this happens on is saving the Tracy settings page? Are you running the latest version of Tracy? Do you have the SessionHandlerDB module installed? If so, does it make a difference if you uninstall it?

Nice one @Robin S - I think I prefer that in general anyway - less mouse distance to cover!

His pearls of wisdom were an attempt to help you and others who may come across a similar situation. I'm out!

This is friendly place and @Robin S has gone out of his way to help support a problem you are having with someone else's module. We all make silly mistakes on occasion - I am certain he was just trying help you eliminate all possibilities. Regardless of what this module did to your admin account, it is always possible to edit and add a new account with superuser rights via the API, so there should have been no need to reinstall a so called completely f'ed installation. Please just ask and we'll do our best to help.

That seems to take care of things!

FYI - there are still some issues with the new tree submenus - some unpublished pages just appear blank. Note "Resources" is blank: If you can't reproduce, let me know and I'll see if I can figure out why it's only some unpublished pages that are doing this.

Thanks @Robin S for looking into that - glad it sorted itself out. I am tempted to run a strtotime() on the "created" date before passing it to date() to prevent this from possibly happening, but might wait to see if it appears again before worrying about it. Cheers, Adrian

Hi @Robin S - thanks for confirming the Captain Hook and form builder template fixes. That issue on the PW Info panel is very weird. The created field for that image is already a string rather than a timestamp, but I haven't ever seen that. I know how to fix, but it would be helpful to know why it is like that in the first place - do you have any special settings on that image field? Is the error on all your pages with images? PS Just did a little testing and it looks like it is likely only with images in repeaters that we even get to this line in the code, but even so, I am still getting a timestamp returned. I would expect it has something to do with outputformatting being on, but I still can't seem to replicate - at thoughts at your end?

@Robin S Ok, back to the form builder issue. Please try out the attached version. I want to test myself a little more today before committing because I had to move a few things around to get this working. Please let me know how it goes. TracyDebugger.zip

PHP doesn't let you use dashes/hyphens in variable names. Either $ground_equipment or $groundEquipment will work.

Works for me!

Thanks @Robin S - I am bad at remembering that New version should fix everything and should also take care of that extra "\/" that you saw at the start. Can you please confirm that your CaptainHook panel output now looks like this - note the "Site Modules" (along with "Wire Core" and "Wire Modules" section headers) and the way the files now start with just their main folder, eg: AdminCustomFiles/AdminCustomFiles.module compared with the old: /site/modules/AdminCustomFiles/AdminCustomFiles.module I think this new way makes it much easier to scroll down to find what you are looking for. Regarding FormBuilder - yes, I use the forms API. I'll see what I can do about figuring out what the issue might be with the template detection shortly. I have a hunch that it's related to the way I am getting the template of the page - because I am in ini() and not ready() when I need to do this, it's a bit of a hack

Hi @Robin S - sorry it's not working for the form-builder template. I don't use ForBuilder so a little hard to debug, but I'll take a look and see what I can figure out. Regarding the Captain Hook error - no, not related - I added some code recently to split the files into sections - that is what is causing the error for you, but still not sure why you are getting that. Any chance you could debug what the contents of $segments is when the undefined offset is reported? Thanks, Adrian

@Robin S - I just committed a new version with the template restriction options. Let me know if you have any problems. Cheers, Adrian

Hi @Robin S - You're right, there is no option to not show it in an iframe. I am definitely happy to add an option for selected templates though. I'll see what I can do about getting this done for you tomorrow.

Are you sure you don't want && rather than ||