Soma

When I save a page (without any changes) it always says there's 3-4 changes although I haven't done any changes. It turns out the language fields get "unset" and somehow PW makes changes to those fields altough nothing has changed. For example tracking the page save and getting $page->getChanges() I get this unset:headline unset:title title headline and title are language fields. Not sure what's about the title. So the save message shown is Saved: /templates/ (3 changes)

I have a datetime field and using latest dev version, when changing the date and saving, the date field turns out empty after saving. When dropping in master, it works. Edit: It seems only to happen when the user has not the default language. If user uses default language the datetime field works. Also maybe it has to do with that the is localized... So If my user is german the date input format is in german localized. Edit: Yes if I change the input format to not include string dates it works again. So I'm not sure what's about it.

In this case I construct the product urls to have only one main category or use what apeisa said.

apeisa +1

You could also use PWs $config->scripts->add(path) and $config->styles->add(path) to register scripts and output them same way as in the default.php found in templates-admin. https://ryancramerdesign/ProcessWire/blob/master/wire/templates-admin/default.php#L67

Bumpidibump.

It's supposed to be in the template file where you want to output your navigation markup. Not sure I understand the question. Where else should it be?

It is reusable changing the properties in the int. But it was an example for a request of user and team pages. I was working on a little more abstract version but havent continued. It works for small amount of pages but to be more scaleable it would require a different approach. This is just straight forward code and melts your synapses if you look at it for too long. ;-)

Ok found it https://gist.github.com/4335296

I already created a module that does this couple weeks ago. Youll find it on my gist page or in forum. On mobile so toolazy to search it.

Name field isnt unique. A textfield and making it global isnt either.

I've seen processwire.ch is also already in hands of a swiss fotographer. Hmm Why?! I was also thinking to get processwire-cms.ch. Even if doing a redirect to you guys

I made some changes to get rid of the 404 problem and changes some minor stuff to then work with LanguageLocalizedURL module too. Dave could you please take that code https://github.com/somatonic/MarkupSitemapXML/blob/master/MarkupSitemapXML.module and test if it solves your issue before pete accepts the pull request? Thanks

I made some changes to get rid of the 404 problem and changes some minor stuff to then work with LanguageLocalizedURL module too. fmgujju could you please take that code https://github.com/somatonic/MarkupSitemapXML/blob/master/MarkupSitemapXML.module and test if it solves your issue before pete accepts the pull request? Thanks

I have shell scripts to copy the live site to the dev. I could see a tool to export and import content. So it would be possible to work on dev, and let editor edit content on live site. Then reimport content from live to dev, before pushing all from dev to live. But this can give conflicts with content created on live, while at the same time maybe adding content to on dev version. So maybe prone to errors. Really don't know what could be done and in what way, I just know it's very hard to bring a solution, and there hardly any CMS that has this functionalities for a good reason. Migrating content is not what I mean which is easy.

Translation for core admin, we already have repos. To pack all 3rd party module translation into them too I think is not a good idea at all. Better keep them with the module they belong to.

Well you could try to empty assets/cache

Just intalled and added an translation for the inputfield module. Works fine without problems, the translation are shown as it should.

Was wondering if this is the start of using PW tree as a html dom tree?

Never too late Wanze! Corrected my post above... need some sleep too

Then what is the field you use to make that select? Too little questions you ask to be able to help from guessing.

Sorry . Damn mobile reading i missed it. Ok but the answer to your problem is: You have to write children() as it's a method not a property. Some other API can be used both with and without so but in this case i think it doesnt. Maybe still something for Ryan to change in case it's this. Damn again, I shouldn't call from memory when having sleep loss. I think Wanze has a good point below

*ZENSORED* completely missed it once more

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...