adrian

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/

I just came across the same issue with tiny trying to install CK. I just told Ryan about, so hopefully this will be fixed soon, although it doesn't always happen - this was the first time I have come across it.

Some random things to try: Does this load the main page fine? localhost:8888/SREPversion2/posts/ Does it make any difference if the page is not set to hidden? Do you have urlsegments enabled for this template? If so, try with them off. What about the url ending with a slash option - try changing that. Otherwise, re-create on lightning and I'll take a look for you

If you right click on one of the teaser links, what is the address you get if you "Copy Link Address"? Does this match what you expect? Does the Posts page load find if you remove the #page-name identifier from the end of the url?

The video embed module (http://modules.processwire.com/modules/textformatter-video-embed/) works fine with CkEditor.

Sounds like you are really close - I was lazy with the <a href='/articles/ That will go back to the root of your site. You can just change that to: <a href='/sitename/posts/

I know horst will have some great advice shortly, but for now, have a read of this: https://processwire.com/talk/topic/6667-jpegoptimimage/ This module also uses the an exec command and also names the files differently. My first post there notes the issue with images being left behind and mentions that you can extend Pageimage::isVariation to deal with these. I know that horst has been working on some standard naming conventions to make this all a lot easier - again, I am sure he'll enlighten you shortly

This is what you are looking for - some of teppo's handiwork https://processwire.com/talk/topic/6556-module-textarea-markup-inputfield/

Glad you sorted it out - hope the rest of your PW goes more smoothly

Hey Max, Try this in your template for the articles parent page: foreach($page->children as $article){ echo "<a name='".$article->name."'><h2>".$article->title."</h2> <p>".$article->body."</p>"; } That will create the posts one after the other with the title and body and with an <a name> tag that is the fragment identifier. The to link directly to a specific article it would simply be: www.mysite.com/posts/#post-name To create these links in your teaser section you might do something like this: $articles = $pages->get("/articles/")->children("limit=4"); echo "<ul>"; foreach($articles as $article) { echo "<li><a href='/articles/#".$article->name."'>".$article->title."</a></li>"; } echo "</ul>"; That should work just fine!

Hi aren, I just committed an update to Custom Upload Names for you. It now has an option to generate a random string at a length of your specification. Please take a look and let me know if you need any assistance.

So long as you are loading the module on the front end like that, the refresh shouldn't be relevant. The refresh was only if you wanted to do the autoload, but this is much better. I wasn't think about adding the load to the page containing the form - much easier than hooking - good thinking

Ok, it all makes sense now Ideally it would be best if you could hook into the point before the form builder saves the page - not sure what that hook is - sorry. But, if you want to quickly test, the autoload = true option works, you just have to remember to refresh your modules: Modules > Refresh after you make that change to the info.json file that I mentioned above. Do that and I think the emails should send fine even via the formbuilder user page creation. It shouldn't be a huge problem to leave the module autoload because it checks to make sure that the page being saved has the user template, so it shouldn't affect any other pages on the front-end. Let me know if that works for you.

I just tested this which is how I would expect form builder is probably creating the page and it also works: $modules->get("EmailNewUser"); $p = new Page(); $p->name = "me"; $p->parent = $pages->get(29); $p->template = $templates->get("user"); $p->email = "me@gmail.com"; $p->of(false); $p->save(); So the only things I can think of are that the module is not being loaded. See here that again I am manually loading it, but if you change it to autoload in the module, you should be ok. The other thing to clarify - is the form definitely creating and saving the email address? I am not really a form builder user, but perhaps if you can explain your exact configuration I can play around with it and test at my end.

Hi Mont, Page fields are arrays so if there is only one expected result: echo $page->promoting_club->first()->title; Or if you want to list them all out, you can foreach: foreach($page->Classes as $class) echo $class->title; or you can use implode (https://processwire.com/talk/topic/5098-new-wirearray-api-additions-on-dev/): echo $page->Classes->implode(', ', 'title');

No problem installing TinyMCE here. Did you hit the enter button on your keyboard, rather than clicking the Download and Install button? There was some weird behavior with this until the commits over the weekend.

Not sure what you mean about the last rule not working. Leaving off the closing ?> in php is recommended when the entire file is php. I am sure there are more complete explanations out there, but take a read of this one: http://developer.sugarcrm.com/2011/05/06/why-we-dont-using-closing-php-tags/ However it looks like you are swapping in and out of html / php, so you will need to close the tags in this case.

For 500 errors, take a read of this: http://processwire.com/docs/tutorials/troubleshooting-guide/

Can you load up other files from the PW root folder in your browser? Please check the permission of the install.php file itself and make sure it matches the permission (eg 644) and also the owner and group of the index.php file - since you got the Get Started button to load I am guessing the index.php file loaded ok. Do you have any other sites running on that server? Any chance their could be some modsecurity or htaccess rules that are blocking the install.php file? Can you access it if you temporarily rename it to something else like test.php?

@tobaco - I am not seeing that issue, but I am missing several site modules from the list. Perhaps you should add a comment to my Github issue: https://github.com/ryancramerdesign/ProcessWireUpgrade/issues/2 or start a new one ?

Glad that got you going until a proper fix is in place. Hopefully these two posts and your link to your other issue will bump that thread for the multi-language gurus too!

Hi Ronnie, I don't know too much about UTF conversions (the curse of being a native English speaker), but could you please try changing this line from: return json_encode($this->getNew()); to: return json_encode($this->getNew(), JSON_UNESCAPED_UNICODE); OR, If you don't have php 5.4+ then you instead of the above change, you need to add this function somewhere in the MigratorWordpress file: public function raw_json_encode($input) { return preg_replace_callback( '/\\\\u([0-9a-zA-Z]{4})/', function ($matches) { return mb_convert_encoding(pack('H*',$matches[1]),'UTF-8','UTF-16'); }, json_encode($input) ); } and then use: return raw_json_encode($this->getNew()); Please let us know if that works and we'll get it updated.

Hey Peter, If there is more than one value in the page field array, then looping is likely what you want, but if the page field is set to only allow one option, then you are better off with your good friend "first": $page->course_detail_level->first()->title

@Didjee - Looks like Ryan may have taken care of most of this, but not quite all. It is an SQL settings issue - certain settings come by default in MySQL 5.6.x, but can also be present on other versions. Does adding that field (column) to the pages DB table take care of it? I'll let Ryan know, but it would be good if you could confirm that fixes things fully.