adrian

You can even just do $pages->find ..... when bootstrapping in PW 3

The changes I made will only affect the console - it's just a matter of whether the encoding change breaks anything else. I checked the pageNameUTF8 sanitizer (because it was the issue that you had with that which resulted in the change that deleted "+" signs) and that still works great, so hopefully we are good

Ok, bit of a rushed fix, but hopefully I haven't broken anything else regarding console encoding. Please let me know how you go with the latest version.

I found it - the "++" is being lost, so it's processing: echo $i ; hence the continuous loop! Must be some encoding issue. I was url encoding, but I stopped doing that to fix another issue. I will revisit and see what I can do to fix. Thanks for reporting.

Not sure yet, but note that it works fine in the Template Editor - just use the Test button / CTRL+Enter. Let me see if I can see out why the console is misbehaving with that. The console is ajax driven, whereas the template editor/tester isn't.

You might be able to do a: bd($this->path); before that line (if you have Tracy installed). Depending on when the CacheFile.php is loaded, this may or may not work. Turning on Tracy's Dump Recorder and Preserve Dumps option may also help. Alternatively you could do: wire('log')->save('testing', $this->path); and then check the value recorded in the 'testing' log file.

Do you think that log entry is related? Have you checked the value of $this->path when this is called (line 208 of CacheFile.php)? $dir = new DirectoryIterator($this->path);

Awesome! It also seems like the w3.org version that we're now using is significantly faster - I was typically getting 750 to 1000ms times on the validator.nu service - now it's around 500ms.

Honestly it looks like you module might be more complete - you are using a js code editor which would make for a much nicer editing experience and it looks like your use of php file tree also makes for a better interface. I don't think this should be hidden at all - I think I'd rather see it in the modules directory as well as Nico's, rather than being lost.

Hi @Juergen - please try the latest commit - I switched it from using validator.nu to validator.w3.org/nu/ and it seems to be fine now. They both use the same checker so hopefully everything will be fine. I have a feeling that this might be a bit of a moving target though, so if anyone ever comes across issues with it, let me know and I'll try to get it working again.

Does this only happen with this template? Does it happen with ML support disabled? Any third party modules that might be affecting the page name/title?

We have a team of keeners - I think that you @szabesz are definitely one of us now too

I am not saying that at all. Nico is working at an agency these days that is mostly using MeteorJS, so I don't think he has much time to maintain his modules. I just thought it might be worth contacting him and seeing if perhaps you could take over his module, or let us know what advantages yours has over his. We're just all keen on limiting the number of module duplicates that WP suffers with - certainly not trying to diminish your efforts at all - sorry if it came across that way. I wasn't even sure if you knew about his module so it was also a bit of a heads up in that regard. Keep up the great work!

No problem at all - we all received lots of thoughtful advice when we started with PW and as you have seen we try hard to return that favor. It's always great to see new users and to see them start to contribute when they feel able!

Hi @flyrs88 - welcome to PW and the forums! What you are looking for is: "include=hidden" You can also use "include=all" to find hidden and unpublished pages. Enjoy your PW journey!

Give us chance We will need some more info. Is ./inquiries/ really pointing to a PW page that has the inquiries.php template assigned to it? Is that page definitely being loaded? If that page is being loaded, what do you get when you dump $_POST?

I am probably the wrong person to answer ML questions, since I only just started using it myself, but you mention: Remember that to get /fr/about/ etc you need to set the name for the site's homepage in French to be "fr". The /fr/ in the url is not based on anything set under Setup > Languages.

$newrole = new Role(); $newrole->name= $userrole; $newrole->save();

Well it depends - if you have the tire child/subpages already setup and they won't change, then using field pairings to ignore the title, you can exclude it from the CSV file. It really depends on whether this is a one time import or whether the client will be using it to update the site and how their csv will be structured. Anyway it sounds like you have a handle on how the module works - now it's up to you to decide the best approach.

Just an FYI, when using the console, d() is usually more useful than bd() as it will put the results at the bottom of the console panel, rather than needing to open the dumps panel to see the results.

Thanks for sharing @fbg13 - just so you know, we already have: http://modules.processwire.com/modules/template-editor/ and there is @tpr's fork which adds module file editing as well: https://github.com/rolandtoth/ProcessTemplateEditor It might be worth trying to consolidate the two modules - I am not sure the feature set of yours vs @Nico Knoll's and @tpr's fork. I know Nico has been quiet around here of late - perhaps you or @tpr could take over with one definitive module for this?

Hi @Juergen - I think what you have come across is a POST size limit on the validator.nu site. You can confirm this by entering: bd(static::$pageHtml,'pageHTML', array('maxLength' => 1000000)); as the last line of this function: https://github.com/adrianbj/TracyDebugger/blob/master/TracyDebugger.module#L784 You may need the Dumps Recorder - I didn't check if the standard dumps panel retains this dump. If you then copy and paste this into: https://validator.nu/ using the "Text Field" option. You'll likely get a "bad gateway" error. If so, then that is the issue, although I am not sure what to do about it at the moment - I don't know whether they recently changed that limit (I have asked here: https://github.com/validator/validator/issues/371) - I am also seeing it here depending on the size of DOM of my page - horst's ALIF module puts it over the limit for me. As for the tracy-debug divs being shown when clicking the link, that is confusing and a little concerning as it looks like the validator is getting access to the Tracy debug bar, which is shouldn't have. Any chance you could let me know the URL of the site (PM if you want) so I can take a look at that?

There are still some unsolved issues when installing (or maybe it's exporting?) a module which has required or requiredby dependencies. To be honest it's been a while since I looked at this. I would like to revisit it because it has the potential to be a huge timesaver. I am also thinking of implementing this functionality (https://processwire.com/talk/topic/14117-module-settings-import-export/) into it. If I can make some time for it, I'll see what I can do about sorting out these issues and getting it published.

I am not sure the best thing that BCE can do here - it seems that in PHP it's not really possible to convert encoding without knowing what it is and it's impossible to determine the encoding completely reliably. This seems like the most likely candidate for a solution: http://stackoverflow.com/a/7980354/1524576 but there are still no guarantees, but maybe it's worth trying? I know Excel can be a pain and I was reading a little more here: https://help.surveygizmo.com/help/encode-an-excel-file-to-utf-8-or-utf-16 - it mentions that: But when I save an excel file to CSV on my Mac, it is automatically UTF-8, so I don't know what is going on. Maybe that article is outdated as it refers to 1999 to 2010 and I am running Excel 2011?

This might be worth a look: https://github.com/ryancramerdesign/ProcessWire/blob/7e8c7c6836282b6b64de81263f5aaa8112fd51ae/wire/core/Process.php#L328