apeisa

I think only thing that is lost datawise are user passwords, since they have salt in filesystem. All code are lost of course, but data should be fine. First: take backups of your current database to prevent further catastrophem

First one.

Yep, and that is little shame. I symlink with wire folder and translations work fine. Would love to symlink site modules too. But as long ad they come from github updating is not an issue. And of course always possible to create some server side scripts to keep modules up to date..

What I meant was repo for each language per module (just like there is multiple repos for core translations). Languages comes from different authors than the actual module. not sure though, might be easier to have i18n folder within module repo.

Well, I didn't meant "apps" in general (we have build multiple apps already: full featured event management, trusted election voting tool, simple discussions, e-commerce.. you name it ). What I meant is when the actual need is to have "app type of an intranet" (instead of "website type of intranet", mainly used to share information), with instant messaging, file sharing, projects & tasks, private settings, profiles etc... all doable with PW, but there is nothing out of the box and lot's of work ahead. If I had to build that kind of application, I would definitely do it with PW. But there are many great alternatives already solving the exactly same problem.

We have noticed that if discussion goes to that level (why pw is better than wp/drupal/modx/any other system) then we are already little late on the game (there are more everything with drupal, wp, sharepoint, anything really, you always lose when comparing on paper..). Angle should be "why we can understand your need best". After client and you both believe that it is great match, then technology will never be an issue. "I have never heard about that system, but if that is what is needed to best fulfill our needs, then go for it." Although I do enjoy personally chatting and comparing the strengths, it actually adds very little value for customer. Of course if project is clearly something specific from some of the areas where PW is not strong (intranet applications, e-commerce, community sites), then by all means be honest and open with that.

Your code looks fine to me, not sure what is wrong here.

Delivering language packs through module download is one way to go. Other one is having github repo per language. Also when this will be decided, there should be possibility to mention translations (with credits for translators) in modules.processwire.com listing.

Ah, we had the same issue just few days ago. Still thinking about best fix. It does need some kind of background pull method and serving only from cache. It was nasty one to debug because nothing came to logs. We just got site halting, but no mysql errors of any kind.

There are lot's of things to try on link Adam provided. I would assume it is something gone bad on mysql update, server restart or something like that.

Definitely money worth module, given it is implemented right.

Doolak, check out the language alternate fields, should help on your title / multilang title problem: http://processwire.com/api/multi-language-support/multi-language-fields/#language-alternate-fields

Simplest would be to use Ryan's web service module. It is pretty straightforward and we are here to help with it.

Not sure, but TextFormatters probably can be used through API too?

Is your comments field name "comments"?

Process Data import expects data to be either in xml or json, so no help here. Custom format, custom import.

Haha, I didn't notice that Pete is such handsome looking fellow before Joss threw that twins comment

PHP version is definitely a hard limit and yes, you should except more from your host.

There ain't themes on EE and PW because they don't generate markup => very hard to provide any kind of theming.

I like the idea a lot! Translating complex modules like form builder I often hit on the same wall: where does that string comes from?

<?php $latest_portfolio = $pages->get("/referenzen")->children(); foreach($latest_portfolio as $item) { $thumb = $item->portfolio_image->size(160); echo '<a href="' . $thumb->url . '"> <img src="' . $thumb->url . '" alt="' . $thumb->description . '" </a>'; } ?> Change $page => $item

What is that weird singing stuff Pete? Are you ok?

http://processwire.com/talk/topic/2516-in-page-editing-createjs-createphp/

That is really special edge case, I don't think I'll take this module into that direction, sorry Marc. But of course you could use this module as a starting point for your need for sure. Difficult to say how to achieve that goal though...

That is how I usually have my tags organized. And having things this way came super helpful in one project: Client wanted to automate most of the content rotating on the frontpage and main sections. Rotation needed be based on time - some articles were about winter, some about christmas, some about summer, some about some holidays in between etc. They had already tagged all their articles (200+) with tags (about 20) and even the thought about choosing "active months" or "startdate - enddate" for each article felt taunting. What we did was to extend those tags to have "active months" selections. This needed only little additional logic, but was a breeze for client to setup (editing 20 tags instead of 200 pages). And if someone decides to move Christmas from December to July... well - we are ready for it! And no - I didn't have a clue about that kind of "autorotation" idea when I build the site.