adrian

I haven't tested, but from memory, I think this is what you need: $t = $templates->get('basic-page'); $f = $t->fieldgroup->getField('fieldname', true); echo $f->cropSettings;

Thanks vegardw for spotting this. Would you mind filing a bug report on Github please?

Hey charger - woke up with an obvious solution. I just committed an update that should take care of your needs. Now the temporary filename is: original-filename.upload.tmp.pdf Hope that works well for you. Thanks for letting me know about this.

Sorry now I understand - it's the writing of the description that is the problem - makes total sense I often use this module with images (so not an issue), and when I do it with PDFs and other files I haven't ever used $file->description so I haven't had this issue yet. The tricky thing about trying to fix this is that filename formats that use fields that aren't available at upload (like description) need to be renamed on save, but if you don't want the name to also change on each future file save (which you wouldn't given that you are including the date in the filename), the module needs to know it is the first time the file has been saved, which is why I use the tmp-filename intermediate renaming. Only files named tmp-filename get renamed on save. All others are ignored unless the "Rename on Save" option is checked. It's almost 2am here and this is not a simple fix, so I am sorry, but I think it will have to wait a couple of weeks, but I'll definitely put it on my list and I'll let you know when I have a solution.

Hi charger - sorry, I am not sure what the problem actually is. Because you have chosen to use $file->description the module has to use the tmp-filename option until the page is saved, when the description field is available. If you used $page-name or something else that is already available when the file is uploaded, it will rename fully as soon as it is uploaded. Maybe you have already figured that out though? Why do you need to know which file is which before you save the page? Once the page is saved the names will match the entered descriptions. Perhaps if you could explain your usage scenario I might be able to come up with a solution for you. I am on vacation for the next two weeks though, starting in a few hours, so I might not be able to do anything until then, unless a clear idea emerges and it is easy to implement. I guess I could go with renaming on page save, but that always seemed less elegant - shouldn't be too hard to make it an option though.

It seems like it might be server specific. I just tried again on my local dev setup and it works as I reported in my last post. But then I just tried via lightning.pw and it failed with the same message you are getting. I honestly don't know why though. Do you have another environment you might be able to test with?

You don't need to, but I think lists are more semantically correct in this case. I am sure someone with a little more time right now will have a more complete explanation for you.

Hey Max, You want the <ul> and </ul> outside the foreach and then use li inside: <li class="articlePost">

Good point! I will have a need for this early next year. If it hasn't been tackled, I'l look into it then.

It's a tough balance, but I remember vividly once being told that one of my sites looks too much like yahoo and not enough like google - it felt a little insulting at the time, but I think it was valid and a good description. I have AdBlockPlus on so I had never seen all the adds before, but when you do, I have to say that I think cmscritic looks a little too yahoo as well

Not so much feedback on the site structure, but you should now that your banner link to "Website Builders Critic" tries to open in a popup and gets blocked by Chrome. Also, there is a broken image on that Joomla page:

Hey Tom, This sounds great! Maybe it already does this, but just a quick suggestion - would it work to have the wildcard used in the destination path so that: with your example /programs/* rule: /programs/my-program/ would get redirected to /about/programs/my-program/

Hey Marty, Migrator should handle Page field creation correctly - I was doing lots of testing yesterday with WP migration and the categories page field was working perfectly. The only caveat I am currently aware of is that the page field must have "Parent of selectable page(s)" defined to be included in the migration. I am planning on removing this limitation in the next major enhancement. If you manage to test further and find that it is a repeatable bug with migrator, please let me know and I'll take care of it. I will be offline for the next two weeks starting tomorrow, but will get to it after that. PS Don't forgetwhen using Migrator you should use the Backup option when importing so you can easily restore if something doesn't go as expected. Also, please always check for the latest version - it has been getting lots of small updates lately.

Sorry - no I am not suggesting you modify the core - it was just meant to be some info to show where the sanitizing of the name is occurring. I just tested an image upload that I named: 名未命.png and it worked perfectly with Custom Upload Names installed - it was renamed to exactly what the rule specified. Without it installed it still uploaded but got renamed to png.png which is a bit weird, but it still worked. What version of PW are you running. I am running latest dev. Does it make a difference for you if you upgrade?

Hi Mary, This is pretty much my standard solution: https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?p=15919 It's pretty straight-forward - I think the only modifications I have made are to allow it to redirect back to the page where they logged in from. You could easily have it redirect to their member page though.

Thanks for the links Andi although they seem to be all about db conversion - with migrator we don't have access to the db, just the exported xml from WP. The biggest problem I am having is dealing with escaped unicode characters when using json_decode. I can use the JSON_UNESCAPED_UNICODE option, but that doesn't actually seem to help much come decoding time during import. So at the moment I am not using that setting and instead just before decode I am using: preg_replace('/\\\u([0-9a-z]{4})/', '$1;', $json); This results in everything rendering well. Most characters come through as normal utf8 and those that don't get converted to hex entities, but I don't really want these stored in the database like this (and they appear as hex in plain text fields and of course in the html view in RTE fields). I have tried several snippets to convert these back to utf8, but with no luck. I feel like I might be close - just need the right combination of conversions in the right order, but it has eluded me so far!

I decided to commit the changes that got me close - everything works, except for the hexidecimal entities when in edit mode for the title. Not ideal, but I wanted to commit some other fixes for properly resizing images in RTE fields to match the dimensions from the WP source, so thought I'd throw the encoding changes in there too in case you want to test. Anyone have any ideas on properly fixing the encoding - please

Firstly, the $session->password will never work, because I am not using eval to pass the contents of the email, but rather using the {} as a replacement mechanism. The problem with getting a password manually entered via the API was that I was using the InputfieldPassword::processInput hook to grab the password before it is encoded. This won't be triggered when the password is set via the API. I just committed an update that uses the Password::setPass hook instead and it seems to be working well in all scenarios, including setting the password via the API. Could you please test and let me know if that fixes things for you?

What about hover links for the main admin theme?

Glad to hear we are part way there. Unfortunately I am struggling to get this fully correct. I don't think I really want to be converting to htmlentities like I did - while it works in the body field, it is obviously causing problems in the title field. I have tried numerous combinations now and still not quite succeeded. The closest I got was having everything appear correct, except for edit mode for the title. Is there someone out there is non-English speaking land who deals with these characters all the time who knows the right way to do this. The problem is getting the escaped unicode characters from the json back to normal utf8 characters. I could keep stumbling through, but someone must know the right way. Stack Overflow hasn't been very useful - all solutions come up short - either that, or I am missing something obvious. Big thanks to anyone who can help out

I am only testing via the admin at the moment, but everything seems to be working here whether the "Generate Password" option is checked or not. In either case I can manually enter a password and that is the one that gets emailed out. If it isn't checked, and I don't manually enter one, I get a warning that the email wasn't sent because the password wasn't set, but if I do manually set it, it works fine. What exact code are you using to create the user and add the password?

Hi davo - sorry not exactly sure what you mean. I can't see anything in the latest commit that would have change the password behavior. Can you try to explain a little differently what you mean.

Actually I was just working on filename cleaning for Migrator and learned a little more I played around with sanitizer->filename and didn't achieve what I wanted, so I ended up making use of: https://github.com/ryancramerdesign/ProcessWire/blob/7b9730d43e6eda8bd27841a4811a1b9737bfe903/wire/core/Pagefiles.php#L302 public function cleanBasename($basename, $originalize = false, $allowDots = true, $translate = false) Does that translate option help for you guys? This is where it is used during Pagefile::install (which is when a file is added to the system) https://github.com/ryancramerdesign/ProcessWire/blob/7b9730d43e6eda8bd27841a4811a1b9737bfe903/wire/core/Pagefile.php#L91 Notice that it is set to true here, even though the default for the function is false.

Just to follow up, I have made a change to the Worpdress Migrator which should hopefully handle all non latin characters. I am waiting on Nico to accept my pull request, so until then, you can grab my forked version at: https://github.com/adrianbj/MigratorWordpress You should also grab the latest version of Migrator itself as there is a fix for certain image filenames coming from WP that were not being properly cleaned and hence not being embedded into the RTE field. Please let me know if that fixes your problems Ronnie. On a side note, that commit also swaps out TinyMCE for CkEditor, so now WP to PW migrations won't try to use TinyMCE. I hope to find some time shortly (unless Nico beats me to it - please feel free to ) to handle other page content structures from WP, in particular the type where you have Header and Paragraph columns in the page editor, which are stored in meta_key/meta_value in the exported xml file.

Hi guys, A quick guess here - I think PW itself is likely stripping all the non latin characters from the filename as the first step. So if there are no latin characters at all, there is nothing left and so the file is rejected. If there is at least one latin character then it can continue to the point where my module hooks in and sets the new filename. I think these are the two relevant spots in the PW core: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/WireUpload.php#L213 https://github.com/ryancramerdesign/ProcessWire/blob/a8024bb49785370aa2e3867bd683094663cfeabf/wire/core/Pagefiles.php#L264 Not really sure what can be done about this at the moment. Here is one other relevant post: https://processwire.com/talk/topic/4387-is-it-possible-to-retain-non-english-filenames/