adrian

@MilenKo - I don't know why this is proving so problematic for you. I haven't ever imported a WP blog into the PW homepage - always into /blog/, but it has always worked perfectly and I have never had to create any fields ahead of time, including the comment fields. The pending status is a known issue. I had been waiting on the response to this: https://github.com/ryancramerdesign/ProcessWire/issues/1034, which ended up here: https://github.com/processwire/processwire-issues/issues/88 - it looks like it can be solved now.

@DL7 I haven't used this module, but I see that it's not autoload in templates so try this before you save the page via the API: $modules->get("PublishToTwitter");

Hi @Soma - not sure if you're still supporting this module, but there is a conflict with the new expandable Pages > Tree menu. With this module installed, the page title appears blank. Please let me know if you have any trouble reproducing.

That's out of my hands - will have to get @martijn-geerts himself to fix that.

I assume you are talking about the PW modules directory? I have just deleted the "martijn" account which had no modules.

Hi @wbertl - firstly, welcome to the forums! Please upgrade to the latest version which should fix the issue for you.

@gmclelland - latest version includes node_modules and sass-cache as default directories to exclude. On an unrelated note, I have also added a new "Selector Queries" section to the PW Debug panel. This shows you all the selector calls made during the current page load. This post also includes a Console Panel snippet idea. If you need to look up a page, template or field ID, this snippet will return the name, title, label, edit and view links, etc. Just enter the ID and the type and run. I have saved it as "Info from ID", but you can choose whatever name you want. Code included in a spoiler below.

@MilenKo - if you fix that error and posts are still not being imported fully, PM me your XML file (if you can) and I'll take a look - it should work fine.

Ok, that sounds reasonable Scanning will only happen if you have the ToDo panel enabled - disabling the panel would do the same as what you are suggesting, unless I am not fully understanding ?

But that's what the "Ignore Directories" option is for. Are you suggesting that I should hard code in those bower, sass, node_modules etc, so you don't need to manually add them?

@gmclelland - yes, by default it is just the files inside /site/templates/ and all it's subfolders, but it can also include /site/modules/ if you've checked that option. Yes, it is a very good idea to add sass, bower, etc files to the Ignore Directories. What feature exactly do you want to turn off?

Put this in your site/ready.php file: $this->addHookAfter('Session::loginSuccess', null, function($event) { if($this->wire('user')->hasRole("target-role")) $this->wire('session')->redirect("other-url"); });

A little OT, but the Language Switcher in AdminOnSterdoids is awesome for working with the the multi-language capabilities of BCE because it let you switch languages from a dropdown on the top menu.

@GKrabach - does the frontend of the site work correctly? Homepage and others? Maybe have a read through this: https://processwire.com/docs/tutorials/troubleshooting-guide/page2

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!