ryan

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.

PW populates your config variables to the module in the time between __construct() and init(). So when init() is called, your config variables have already been populated to the module. As a result, the __construct() is a good place to populate defaults. In your case, you could do this in your __construct(): foreach(self::$defaults as $key => $value) $this->set($key, $value); I don't think that a Pageimage (singular) is applicable here since all image fields are multi-image fields behind the scenes. The existence of a single image field is just a type of output formatting used on the front end of your site. I believe output formatting is turned off in the case of your module, so you should be able to assume that all image fields are multi image fields (Pageimages). As a result, I would perform the check like this: if($v instanceof Pageimages && count($v)) { // ... }

It depends on the fieldtype. Though for most fieldtypes, values are optional. But in order to create a page from the admin or the API, it must have either a name or a title. If no name is supplied from the API, PW will try to create one from the title. Yes, you can choose to specify only the width or only the height, and the other dimension will resize proportionally. If both width and height are specified then it will crop as needed to reach your target dimension, and it will never stretch a photo non-proportionally. It's pretty much the same as with any other web site where you copy the files and database. However, PW does have a Profile Export module that lets you create a site profile that can be imported elsewhere. This can be useful for migration, as PW's installer takes care of the installation for you.

$student = $users->add('norboo'); $student->pass = 'some password'; $student->save(); $studentPage = new Page(); $studentPage->parent = '/path/to/student/pages/'; $studentPage->template = 'student'; $studentPage->name = 'norboo'; $studentPage->title = "Norboo's Student page"; $studentPage->save(); $session->redirect($studentPage->url); If you need something to hold an image and some text, this is what the Image fieldtype already does. No reason to use repeaters when the Image fieldtype can already do this more efficiently. The fieldtype's settings will let you specify how many images you want to allow and how big of a text field should be provided with each image.

Add this to the top of your getModuleConfigInputfields() function. This should also solve the undefined variable notices: $data = array_merge(self::$defaults, $data);

I think so. Parent pages don't currently support multiple built-in sort fields for children (like in the API), so it would have to be one sort field or the other. That makes it difficult to pin a page in the admin, even if you can do it easily in your own site. Down the road a bit I think we'll have to add multiple sort fields, which would solve this pretty easily.

I think the problem might be that $session already keeps it's own 'error' function and variable, which is an array. So it might just be a matter of naming and using something like 'login_error' rather than 'error'. Your current solution works because it's likely resolving to a session variable named blank or "0". But if you tried to do something similar anywhere else, then you'd have unpredictable behavior. As a result, I think it's best to give $session an actual variable name that you want to use, like this: $session->login_error = 'your message here'; and retrieve it like this: echo '<p>' . $session->login_error . '</p>'; using set() and get() is also fine, but not necessary.