Soma

I was thinking about this alot in the past since translations are in PW. I can't remember if it was discussed already, I think only little. That's a valid question or concern I think we should have to recommendations for 3rd-party modules. I don't think it's tedious, just a question of how you handle it. Translations in core was added not so long a go and was a sponsored by Antii's company (?) feature Ryan added. It's s very well implemented but in some areas still a little rough (no offend Ryan). It works all well and even resulted having language text fields (adds inputfield for each language automaticly) and even possible to have alternate language fields (fieldname_de,fieldname_en) which is awesome. Creating language packs is hard work, but it's always possible to extend some things or create helpers int he future (did one recently created one here for Radek http://processwire.com/talk/topic/2540-czech-localization-textdomainhelpermodule/). Adding languages is easy but I still am not happy with the interface where the json files are stored. Hard to get an overview and deleting all is cumbersome (70+ files) manually. But the system is there and it's maybe only a matter of building a more advanced manager for the files, which shouldn't bee too difficult. Just takes some time. We are still not even a year into PW added translation and people are now slowly coming in and start to point out issues cause they're using it. So thanks for everyone sharing he's thought to show there's some need. I know Ryan doesn't use multilanguage feature and most western don't. We in Switzerland have the opposite, 90% of the sites have at least 3-4 languages. Mostly we do the front-end translation using yaml or php vars to have translatable strings at it doesn't have to be done with PW. Also, rarely we use modules that then would need translation for end users and most of the time the editors are one-languaged group of people. So haven't really come to using it that features much apart from the core admin. Some things may could be considered as mandatory for modules added to repository: All 3rdparty module should have it's text strings translateable. (some module were built before core translation, like Thumbnails) All 3rdparty module should have some folder for translation to be added. So other's translating it can add the json file.

Awesome! Thanks Ryan for the description. Some work for the cheatsheet...

These look like its a user select. Ids are in the range of admin etc. You should not choor title but name as the label as users dont have a title field.

Ok I meant, "meet and eat". Ok then we are already 2.

Hey guys of central europe and near Switzerland. Any interest in doing a conference/meeting in Switzerland, this year or any time in the near future? I was thinking about a location in Zurich. Event if it's just to meat and eat, drink and have some fun.

If the subdomain points (htaccess) to your domain there's no need to do redirect. It's like an alias and in your code you can test the domain the user browser sends the request aka Ryan code.

With ProcessWire no problem. Just use a repeater or child pages for the content data you need. Then some foreach to output data in the format your slider js plugin needs it. There's no module for PW because it's so easy to implement those things. With a module you're limited at best and would have to change things at the end anyway. I don't understand the difference between a normal slider and an animated slider.

You maybe have to simply do a $page->options->removeAll(), to then populate it with the checked again.

What if there's a problem. So you would need to have a test before, and backup all data before. And if deploying to a live site, you'd have to disable it first too in case. I can see this could cause also more time and trouble than doing it manually anyway. Depends a lot on what you need to change or implement. Doing just template/field synchronizing maybe a good way to start and can save time, but a full blown deploy tool I hardly would trust in it and have always fear it doesn't work and causing more work at the end. There's so many things to consider and what can go wrong will go wrong. I think we'd all love some sort of such a feature anyway. Even if it's just export template/fields and import them in a save way.

Maybe I also point out this thread. http://processwire.com/talk/topic/2089-create-simple-forms-using-api/ And yes you can change markup and classes to some extend as seen in this thread.

Natetronn, that link doesn't work. BTW. Looking at the textarea, there's already a placeholder text you can enter. Maybe you need to update to latest dev version.

Just rename it an you're done. Or move it and it will still work. Hard to stop PW.

Edit well if there not too many projects you could try and evaluate the dates and store them on runtime to sort by that value afterwards when you loop them out. $pa = $pages->find("template=project"); if(count($pa)){ foreach($pa as $p){ if(!$p->numChildren) continue; // no assignments // store a temporary value to the project page $p->tmp_date = $p->children("sort=-due_date")->first()->due_date; } // output the projects foreach($pa->sort("-tmp_date") as $p){ echo "<li>$p->title</li>"; if(!$p->numChildren) continue; foreach($p->children("sort=-due_date") as $a){ // output assignments } } } This will work well if you don't have thousands of pages. The module approach would be the more efficient and scaleable.

I don't see an easy option to do that, but with a little module you could on each save of a child page update a date field on the parent. Then sort it by that field. Let us know so we can help you get started.

I think you hit here some full text mysql stopwords or number get filtered out and it's too short

It's somehow hard to follow you and there always seems to be some last important info missing. Also there is like 3 mixed. - This doesn't work (code) with no further details - How would it be done better, alternatives - How do I use language fields and approaches This would be a whole book about those subjects alone I think you're on the right track to try both approaches. Separate tree for each language or one page multiple languages; Both is possible (quite easily) and each has it's various pros and cons. It's just it can get confusing at times, not only trying to help. It also depends on how you setup the rest of the site apart from /news/. Is the rest of the site multilanguage? Multilanguage fields or alternate language fields. With the latter you could put them in separate "de","en" tabs and with the former you'd have them coupled together. If you have languages on one pages, you can't for example use the published features of PW and would have to implement something to define it and have additional code in templates. With separate trees you would have to somehow link them together using a page reference and it may makes it hard to edit and keep track, but its also possible. Also always remember you can use checkboxes to do something like setting a pages available languages. Using this, you could then set the label displayed in the tree (template advanced settings) to show their title I think. Instead of "title" you'd have something like "title de_pub.label en_pub.label". Where de_pub would be the checkbox field for german.

It doesn't work because the page you're requesting it the /news/ page and not the article itself. Depends where this code lays, but assuming $page is the news page with urls segments, $page->parent->name would be? Also it's a good practice to use if() else checks to see if a url segments is really found if(count($page->urlSegments)) or if($page->urlSegment1). Also it help if you output the vars, segments or page->id to debug and see what values you get and where you actually are.

It doesnt work because english is not a url segment but a real page.

Hey khan great, thanks for sharing your module. I created also various bits of it in templates and not as a module to stay flexible with forms and code. Just by taking a quick look at code, it would be nice to have it translatable. Also it would be nicer to build forms with PW API inputfields. This would make it much easier for styling and such. Keep up the good work.

Pete. There's a missing $langname = ''; #36, the sitemap won't work if debug mode enabled, as the markupcache uses $langname and throws a warning that will give a header already sent error. SOmehow fmgujju seems another problem as if it shows a 404 page, which means the modules doesn't get executed at all or the most likely the init code strpos check doesn't hold true for some reason (the only I changed)

<?php function sitemapListPage($page,$siteMap='') { $siteMap .= "<li><a href='{$page->url}'>{$page->title}</a> "; if($page->numChildren) { $siteMap .= "<ul>"; foreach($page->children as $child) { $siteMap .= "<li><a href='$child->url'>$child->title</a></li>"; sitemapListPage($child,$siteMap); } $siteMap .= "</ul>"; } $siteMap .= "</li>"; return $siteMap; } $outMain .= "<ul class='sitemap'>"; $outMain .= sitemapListPage($pages->get("/")); $outMain .= "</ul>"; You need to pass along the variable. $siteMap='' argument is default to avoid passing an empty one. If defined it will get overwritten ans passed along.

Maybe after you got it working you could use the MarkupSimpleNavigation module to do it

It's exactly what wanze posted. There's no other way than redirect your home to a subpage. It's same as if you would add a redirect in your htaccess.

Ghhk.. Congrats Nik. You level up!

News_Year.title=xyz Or better retrieve the year as page object. Then do News_Year=$yearpage In the selector. Im on mobile too lol