Soma

http://processwire.com/talk/topic/1799-routes-and-rewriting-urls/ If you search a little more there's a couple threads about this subject.

http://cheatsheet.processwire.com/?filter=closest&advanced=1 A quick search with google "processwire closest" reveals: http://cheatsheet.processwire.com/page/built-in-methods-reference/page-closest-selector/

Cool. While at it. I got some 'fixes' for shop modules and will pr it as soon as I get to it.

http://mods.pw/5m

I'm not sure I understand everything, but looks like what is specified in the Page Name module settings is working for backend page creation and API creation. Versal letters are converted correct. Entering "Рaz Дva Тri" converts to "raz-dva-tri" $p = new Page(); $p->template = "basic-page"; $p->parent = 1; $title = "АКЦИИ"; $p->title = $title; $p->name = $sanitizer->pageName($title, Sanitizer::translate); $p->save(); The page is created with name "aktcii" As said you can add missing/new chars to the module settings in admin yourself. I'm not sure you're suggesting to add more to the standard or what. I think whatever languages you're supporting, there's chances that there is an overlap that would make things complicated or impossible. For example in finish there's ö => o, but in german it's ö=oe. So I also have to change the setting for every new site I'm doing, but that's how it is. Also note that things like ц = cz,c or ы = y' is not possible cause the page name only allows ascii chars.

http://cheatsheet.processwire.com/pages/built-in-methods-reference/pages-find-selector/ We're on it and all are things we discussed. Just give us a little more time guys or help us out

This not error but feature. You can configure the conversion yourself in the page name module in admin.

http://bit.ly/1lmsqio But I'm not sure it's what you experience. It's hard to know without seeing examples.

Looks maybe like you have some max-width: 100% in your css for images.

Or simply $children->co_cities->title. Although the naming seems wrong because it seems it's not children but a child and the field is a single page select? So it should be co_city.

Look cumbersome to me cause $cityid is not the id but the page object. So $cityid->title would be enough. No reason to get the page again. If you echo $cityid you will get the ID because of the __toString() method but in fact it's really a page.

This thread title is wrong. TinyMCE IS a module like almost anything in PW. *Hides behind stone*

children() can also have a selector. In fact it's using a find behind the scenes.

I'll say it once again... that's what my form save reminder is for so this doesn't happen when leaving the not saved form. I still think it should be core standard. Ryan seems against it because he is in fear of the wysiwyg that needs special treatment. I see that but would rather accept the challenge cause it is very well possible and all special inputfield just have to make sure they do a form change trigger if needed. There's not really any that currently doesn't work. I think a great software just has to do this otherwise it loses a big point in usability. But maybe thats just me.

Since you have custom sorting, no there's no index. $page->sort would be the sort index from the tree but that would be different once you sort on a custom field possible with ASC or DESC. I'm not sure I understand the logic/context of your "if on Gamma, return 1 for Alpha". Also I'm not sure why you have "include=all" in your query. Just will return all pages including those that user would have no access, unpublished pages etc.. Your script would be one way to do numbering, but $i isn't defined and you would get a notification. $a = $page->siblings('include=all'); $i = 0; foreach($a as $b) { $i++; if ($b == $page) { echo $i; } } So this would give you, if on Gamma page "1" If on Alpha page: "1" Is that what you want? Another way to number pages is using a $key in foreach (zero based): foreach ($page_array as $key => $p) { echo ($key + 1); }

Maybe you can also let us know what PW version, and where this script is run: Template, Module, Bootstrap ... This works as expected for me. Though possible there was some fix. I could image the problem has to do with pages in cache/memory vs pages queried from DB. Once you create a new page and add children to it, the $mypage page is already in memory and $mypage->children() may not return any children cause there was none when you created the page. Though it works for me so looks like children() makes a DB query after all. BTW you don't need $page->of(false), because a newly created page via API has no output formatting yet.

I just was thinking if you possibly create new templates, roles and permission for every new user which may wouldn't scale well.

Please keep english here.

Why do you want to create and set all this things by API? Can't you just use admin UI?

Craig already sowed how. Or what else you mean?

I don't think that would be easy possible as Ryan explained. Repeaters are limited to what you can do. I would think you're better off using child pages under event to do what you want. It would be more correct from a data structure point and open up more selector friendly handling.

It's in the main.js of the theme. There was some fix in ~2.3 for that.

The cms we also use at work has a draft - live system. Save does save the page but its not published and just keeps it until you hit publish. Until published it is marked I a different color. Simple. Not sure how this would be possible with pw.

Why Not simply use the great Fredi module for front end editing? Or use edit links that point to the edit page in pw and append &modal=1 and use some lightbox iframe script. Much less hassle and dead simple.

And I thought I left the hard ones to you.