ryan

I think you'd make your own URL generation process. Lets say you've added a multi-language text field to your templates called 'url_name', you might do something like this, and call this URL() function rather than the url() function attached to every PW page: function URL(Page $page) { $language = wire('user')->language; if($language->isDefault()) return $page->url; $url = ''; foreach($page->parents as $p) { $url = '/' . $p->url_name . $url; } $url = '/' . $language->name . $url . $page->url_name . '/'; return $url; } I think that the slim solution is to use multiple trees. But I agree with the advantages of being able to specify page names in different languages, for the same page. I just don't currently know how to build that in without adding huge amounts of complexity to the system. It's something I will keep thinking about here in case any straightforward technical solutions become apparent.

Are you talking about example 3 from this page? There won't be a simple way to use different page names there since one page can't have multiple names. You could always add your own field to the page to hold it's name in other languages, and have your language-gateway template attempt to load them by that field. But I think that in the case you are describing, multi-tree would be preferable.

Hard to tell without seeing what error is occurring. Check your /site/assets/logs/errors.txt file and see what it says. If you can't find it there, try turning on the developer tools in Chrome: View > Developer > Developer Tools. Then in PW's PageList screen where it's hanging, hit reload. Look at the last request in the 'Network' tab of the Developer Tools. Click on it. Then click either the Preview or Response tab that appears on the right pane. You should see an error message. What does it say?

Pete, sorry I didn't catch your message before you'd figured this out yourself. But it looks to me like you got it right. As you found, repeater pages are kept unpublished+hidden until set otherwise. This is because repeaters may keep one or more 'ready' pages, that are ready to be populated in the admin. If there weren't any ready pages, then your repeater_field->first(); would return null rather than a Page. So if your ready pages were set at 0 for that field, then you'd want to start a new repeater page like this: $field = $fields->get('repeater_field_name'); $newRepeater = $field->type->getBlankRepeaterPage($page, $field); $newRepeater->status = Page::statusOn; // same as removing unpubished+hidden // ...populate any values to repeater... $newRepeater->save(); But you don't need to do this since you appear to have one or more ready pages already being created by the repeater, so your first() method works just fine. I still need to make a simpler API to the repeater field...

Looks good Diogo, thanks for posting. Only thing I wanted to mention is that it may be preferable to get the field value from the Inputfield rather than directly from $input->post. That's because the inputfield may perform some of it's own validation, providing you with a safer value. Though fieldtypes do some validation too, so your method isn't bad either. But getting values from the Inputfields themselves is preferable in many cases. Especially if you wan to display the form again with populated values, like if there's a missing required field or something. So your form processing could look something like this: if($input->post->submit_save) { $form->processInput($input->post); if(!$form->getErrors()) { $mypage->of(false); // turn off output formatting before setting values foreach($mypage->fields as $f) { $mypage->set($f->name, $form->get($f->name)->value); } } }

Great site Soma! Looks like a fantastic hotel and you really show it off nicely. I saw this first on my iPhone and really liked the experience there too.

I haven't used CI enough to comment, but know that others here have and hopefully they will give a better response. I generally like building apps in PW and haven't felt the need to look further for the type of apps I build. But I wanted to mention that some others are apparently using PW and CI together as well. If it's the helper classes that interest you, you might also want to take a look at one that Netcarver introduced us to: Flourish. Seems like it's built around the idea of helper classes rather than a strict framework. I'm pretty impressed with what I see there, and it also seems to play well with PW.

Family is not enforced by the API for new pages. Though it does prevent you from creating a page the traditional way in the admin. If you as the superuser have setup a Page field to allow creating pages somewhere, and you've specified a specific parent and template you want, then that's specific enough so as to override the family setting. Not sure if it should be that way or not. Its just a question of what should override what. I veer towards letting the family setting be more open ended on this stuff. But family settings are relatively new to PW and still marinating in some respects. We may want to refine some of these behaviors over time.

Nice job Antti! Love the site. It's nice to see it running on ProcessWire!

Great module Soma! I've been meaning to add something like this in the admin search too, and look forward to taking a closer look at what you've put together here.

I don't think this is something that can be done in a straightforward manner unless you modify and replace InputfieldPage.module, where this label is assigned. However, it seems like a good idea and we can look at making this an option in the core module for the future.

Currently all users have to have the 'user' template. However, you could add child pages below a user page (or role page) and perhaps keep some of your custom data/settings there. In order to add children to these pages, you have to edit the 'user' or 'role' template and click on it's 'family' tab and update it so that children are allowed.

Thanks for the followup. I didn't see anything in your PHPinfo when I looked yesterday (except possibly the safe_mode setting), but got sidetracked before I could reply. Glad it's all working now.

Thanks for the testing and followup recyclerobot. Interesting about mod_cgi using up all that memory relative to mod_apache. Most servers I work on actually don't have an opcode cache, but I think it's a good thing to have for any PHP app that needs to handle large volumes of traffic. I'm running eAccelerator on this server, though don't think we needed it, but figured it can't hurt.

Not at present. Though could probably be added. Oliver was working on extending some of the built in image functions with his ImageSizerExtended module: https://github.com/oliverwehn/ImageSizerExtended though I don't think that has filter functions, but may be a good place to launch from in adding them.

That's a tough question to answer, because usually we're trying to prevent this sort of thing from a security standpoint. So I think that the solution will involve creating your own template to perform the login. Something like this: <?php if($input->post->user && $input->post->pass) { $username = $sanitizer->username($input->post->user); if($session->login($username, $input->post->pass)) { $session->redirect('/path/to/page/'); } else echo "Login failed"; } Then have your OpenCart page POST the 'user' and 'pass' to the page using that template, when they click a "go to ProcessWire" button, or something like that.

I'm not sure that I understand-- You should be in full control of your markup when you use ProcessWire, so whether you output with line breaks or not, or whatever you want your output style to be, is up to you. The only thing I can think of is perhaps TinyMCE? If so, I suppose that you could remove all whitespace between tags with something like this: $page->body = preg_replace('/>[\s\r\n]+</s', '><', $page->body); ...but I'd worry about unintended side effects, like situations where you really do want two tags on two lines. There is a purpose for whitespace in markup and it's probably not good to throw it out. But if you need to cover a specific situation, a regexp may be a good way to go.

The "site-" at the beginning is required because the .htaccess file knows to block access to sensitive directories/files below all directories beginning with "site-". So while you could use a different naming structure, you'd have to make a lot of changes to your .htaccess file in order to make it secure.

That 403 forbidden message is coming from the web server, not ProcessWire. It looks like something at the server is taking control and interrupting the file post. I would guess that this has to do with a mod_security setting at the server. They don't appear to be ajax upload friendly. If you want to PM me a link to your phpinfo() I'll be happy to take a look. Though I'm guessing only the phpfog support can answer this one for us.

The page statuses are a bitmask so it's possible for there to be multiple statuses on a page, like unpublished and hidden. So it's best to add and remove statuses with the addStatus and removeStatus functions, i.e. $page->addStatus(Page::statusUnpublished); // same as: $page->status = $page->status | Page::statusUnpublished; $page->removeStatus(Page::statusHidden); // same as: $page->status = $page->status & ~Page::statusHidden; You can also check the status of a page by using the is() function: if($page->is(Page::statusUnpublished)) { ... } // same as if($page->status & Page::statusUnpublished) { ... }

Is the web site also running in PW? If so, then PW won't show the login page. But your question makes me think the user is logged into some software other than ProcessWire. The question is, which software are we talking about? That may help us to determine how best to authenticate them with PW too.

The profile exporter is good for launching a new site, but not for migrating an existing one (for the reason you mentioned). For migrating an existing site, I think there's no better way than to copy the files from 1 server to the other (I use rsync) and then dump the database on old server, and import to the new. Then update /site/config.php to account for the new site's database host/login/password.

Very cool. I'm a fan of minimalism taken to this extreme. I just wish I could get away with it. I particularly like the presentation of photographs in the work section. Part of me wishes the photographs appeared site-wide as background texture, rather than just in the work section. Though I can also appreciate the surprise and contrast of keeping them independent.

Soma, if I'm reading it right, the else condition could never occur. We already know that $v is an instance of Pageimages, because the earlier if() statement confirmed that. So the only test here is count($v). If the first one fails, the second one (in the 'else') has to as well. if(count($v) && $v instanceof Pageimages){ $thumb_url = $page->$field->first()->size($size[0],$size[1])->url; } else if(count($v)) $thumb_url = $page->$field->size($size[0],$size[1])->url; As a result, the above could be reduced to this: if(count($v)){ $thumb_url = $page->$field->first()->size($size[0],$size[1])->url; } If you want to test that the second 'else' could never be called, try using your original code segment, but doubling the size of the thumb_url in the 'else' condition. That way you have a landmark (a larger image): if(count($v) && $v instanceof Pageimages){ $thumb_url = $page->$field->first()->size($size[0],$size[1])->url; } else if(count($v)) $thumb_url = $page->$field->size($size[0]*2,$size[1]*2)->url;

Users, roles and permissions are not included in a site profile. The module specifically excludes them. Though if you wanted it to include them, it would just be a matter of removing a line from the module, so will probably make this a configuration option on the next update.