ryan

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.

Good question. I'm not sure there's a simple answer though. What you mentioned about migrating changes directly from the database of WordPress doesn't sound like a safe thing to do with any database-driven CMS. The nature of a relational database is that there will be records in different tables referencing each other, so when you've got two versions of the same database, they would be challenging to merge. As a result, it's a problem if you have two databases going off on different paths of changes if they need to come back together at some point. I use my staging servers for staging things like new template files, modules, new PW versions, etc. I don't usually stage actual content from one server to another. Or if I do, I'm copying and pasting it (in PW admin) from one to the other. But the way I usually stage major content changes is to make them on the live server, but in a staging part of the site (unpublished, hidden or otherwise inaccessible pages). When ready to migrate, I publish or drag the relevant pages to their live home. Note that this is for content, and not for anything that could interfere with the operation of the live site. Anything that could interfere with the live site (templates already in use, modules, versions, etc.) ideally should be staged on a different server. I don't know of a better way than that. It's not perfect, but it's always worked well for me. Longer term, I want ProcessWire to support a workflow that lets a staging server talk to a live server and publish from one to the other (using web services). I already use this workflow on a lot of sites with custom modules, but they are specific enough to the individual sites that they aren't suitable as a broader solution. However, I do think we'll have a broader solution like this in the next 6 months to a year.

Great module Soma! I really like having this functionality, and you've done a nice job putting it together. It's easy to see how useful this is seeing it in action--I will be using this for sure. A few comments: 1. On the module edit screen, I get a bunch of notices about undefined variables. Probably because I'm in debug mode, but wanted to mention it still. 2. I see the defaults in the .module file, but they weren't populated in my config screen, so I was confused about whether the fields needed to be populated or not. If they don't, maybe adding a $field->collapsed = Inputfield::collapsedBlank; to the optional fields would clarify they are optional. You might also add a $field->notes = "If left blank, a default will be provided"; or something like that. 3. When displaying a page that has no image, it shows a broken image. I think it'd be better if it showed a placeholder (WillyC's face?) or just the box with no image in it.

I've got this all working now. It took a little more work than I initially thought, so just need to test for a couple days on this end to make sure I haven't introduced any new bugs.

I'm not sure that I understand the question, but I think I get roughly what you are trying to do here. Because your building something pretty custom, I think you'll be using ProcessWire as a framework more than a CMS here. Though the work involved may be less than if you were using just a framework, though many of the tasks are likely to be similar. I think it would be best to build all of your student-editor needs on the front-end using old fashioned HTML forms rather than PW's admin. Then use PW's API to perform the creating and/or modifying of pages, which you would populate from your forms. That way you've got full control over everything, and are not trying to repurpose the PW admin as something it wasn't designed for. Though you certainly could use the PW admin, but I would be shy about any system that lets someone register and then have admin access (even if limited). Security will be a major consideration here as you build this out.

Modules that extend Process, Inputfield or ModuleJS automatically add any .css or .js files of the same name in the same directory as the .module file.

Thanks for updating your code. Just one more thing there that I don't understand are these lines: $session->set($error, ""); $session->set($error, "Login Failed. Please try again, or use the forgot password link below."); echo "<p class='error'>".$session->get($error)."</p>"; As far as I can tell, $error is an undefined/empty variable. Unless I'm misunderstanding something, shouldn't all of the $error instances instead be 'error' ? like this: $session->set('error', ""); $session->set('error', "Login Failed. Please try again, or use the forgot password link below."); echo "<p class='error'>".$session->get('error')."</p>";

It definitely sounds like the size of the uncompressed images exceeded the size of memory available to PHP. Check what your PHP memory limit is. If it's 128 or less, you may want to bump it up to 256 to better handle large images. I've also occasionally come across an image that GD just won't resize. Whether it's too high of a DPI or what, I don't know. But if you are dealing with print-resolution images, it might not hurt to scale them to a more tangible size (72 dpi) before uploading too.

Beautiful theme! I can't wait to try this one out this afternoon.

PW's admin is built with the intention of administrative users, so doesn't do what you are asking out of the box unless you give each user their own template to edit. However, you may code your front end (site template files) to provide access to any page fields that you want to, and that's the recommended way to give non-administrative users access to manipulate data in your site. From that standpoint, you can do nearly anything, but it does take a little code. The option Diogo mentioned is a nice simple way of handing this kind of stuff. If you can go into more detail about what fields on a page a student might edit, we maybe able to get a rough example going in this thread. Also wanted to mention that you can achieve this on the back-end with a custom module, and it's not that hard to do. But since you mentioned students, I was thinking that sounds more like a front-end scenario.

I think it makes sense, and have recently had the same wish. Adam brought this up a long time ago, and I've been meaning to add it, but just haven't gotten around to it yet. Now that there's been another request for it, I'll push this forward sooner rather than later. Actually now that my mind is on it, I think I'm going to work on it over lunch break. The plan is that when you select a default sort at the template level, the option no longer appears with the page (i.e. template setting, if used, overrides page). If you select 'none' (the default), then it can still be set at the page level. When no sortfield is set, pages sort ascending by the database field 'pages.sort'. When you create pages in the admin, they should get added in the order you create them, as ProcessPageAdd manually sets this. That would look like 'created' order. But when you create pages in the API (or any kind of import process), and don't set the 'sort' field of a page, then they are all going to have the same sort value (0), which makes order unpredictable. I actually modified that yesterday when I was fixing the drag-sort issue that smd found, and committed it this morning. Now $pages->save() takes care of setting a $page->sort value if you don't, so it should be more API friendly. The reason we don't want to default sort by something like 'created' is for the reason Antti mentioned (no ability to manually sort).

For something like that, I think you'll be better off just importing from the API. Probably 70% of the time that I need to do any kind of importing of anything, I just use the API because it usually makes a quick and easy job of it, without having to consider any limitations. But if you want to get image/file descriptions in with the CSV import module, then I would probably create a temporary field to store them in, for import purposes. Then go back and paste a little code in a template to quickly convert them over: foreach($mypages as $p) { $p->of(false); $p->image->description = $p->temp; $p->save(); } Once you've done that, you could then go and delete that 'temp' field from the template.

Count me in to help if needed. I think this may be one that belongs in the core, though have avoided it thus far since it gets the core involved in specific fieldtype output. But this may be an okay compromise to make if done directly in ProcessPageList. Other than that, I think that a module is definitely a good way to do it too.

Thanks for posting Renobird. I'm confused on this section: if($session->login($user, $pass)) { // login successful $session->redirect($page->path); $error =""; $session->set($error, ""); } else { $error =""; $session->set($error, "Login Failed. Please try again, or use the forgot password link below."); } // ... further down echo "<p class='error'>".$session->get($error)."</p>"; It seems like that is just setting a blank session variable? Are you sure you didn't mean for it to be like this? if($session->login($user, $pass)) { // login successful $session->set("error", ""); // note: moved this above the redirect $session->redirect($page->path); }else { $session->set("error", "Login Failed. Please try again, or use the forgot password link below."); } // ... further down echo "<p class='error'>".$session->get('error')."</p>"; Good question--I have no idea. I've been trying to figure this one out for awhile. I have to paste any code in my plain text editor, then manually indent everything with 4 spaces. This editor appears to ignore tabs. Pete's been doing a great job of installing updates for us here, so we'll very likely see improvements here as the IP.Board developers make them.

Good questions RecycleRobot. This is really is going to vary from environment to environment, so my recommendations would be more general. Though awhile back Soma reported that some of his colleagues had run a stresstest called a "proxy sniffer load curves report", and the report came back quite good. But I don't know what all that entailed. I recommend giving it 128M memory (the PHP 5.3 default) or more, in your php.ini. If you need to deal with lots of traffic, it's a good idea for your server to have a PHP opcode cache like APC or eAccelerator. Beyond the server configuration, other performance factors depend on how you use ProcessWire. If you are doing anything heavyweight with the API towards markup generation, or just need to handle lots of traffic, it's a good idea to make use of PW's various caching options. From the template settings, you can tell it to use a cache from the 'cache' tab. Choose settings that maximize the lifetime of the cache, clearing only what you need to cleared when a page is saved. You'll also want to get familiar with the MarkupCache module, which enables you to cache individual pieces of markup in your templates. This is really handy for caching markup that may be expensive to build on every request, like larger navigation trees... or anything you want. You'll also want to look at these best practices for long term scalability, as well as the field autojoin option. If you need to work with a lot of pages in memory at once during the same request, the $pages->uncacheAll(); function can clear memory when you need it (at the expense of having to reload any pages you try to access again). How much memory a Page takes up depends entirely upon how many fields it has and how many are loaded/populated. ProcessWire generally tries to keep Page objects as lightweight as possible, and doesn't load fields until you actually access them. As a result, you could feasibly get thousands of pages in memory if all they had were short 'title' fields. But you might only get a few hundred if those pages have their fields loaded and all in memory at once. PW does create a new directory for each page at present. That behavior will become on-demand in the near future. But at present, this would mean your maximum quantity of pages (at least, pages that can also store files) could be limited by the file system and any hard limits present there. ProcessWire is not compatible with PHP 5.1. If you are running it, I'm not sure how because 5.1 lacks some things that PW depends on. I'm guessing 5.1 was a typo, but if not, let us know as I may have missed something. I recommend running PHP 5.3 if possible to maximize performance. Also, I may be wrong about this, but I had thought that there was some overhead with running PHP as a CGI as opposed to running it as a module. If that's still the case (?), you may benefit from running PHP as an Apache module, but I'm out of area of knowledge on this one.

I was able to duplicate this. The problem was the recently introduced version numbers that are appended to $config->scripts (and $config->styles). InputfieldImage manually adds InputfieldFile.js to $config->scripts, as it always has. But it knows nothing about version numbers. The result was that if you had both a file and an image field on the same template, the same InputfieldFile.js would get included twice (one with version number, one without). All that JS in InputfiledFile.js would also execute twice when you dragged in a file. Thanks for finding this bug--I just committed a fix for this. I don't want to have to append version numbers ever time I manually add a script/style from a module, so I setup PW to ensure uniqueness of these at the time they are added (regardless of version number). I'm not yet sure why the display thumbnails option would make a difference here, but will experiment more. Please let me know if you find any issues remain. Thanks, Ryan

You can always create your own login page (and template) and have full control over the flow there. Logging in a user in PW is as simple as calling $session->login('name', 'pass'); If it authenticates, it returns a $user. If it doesn't, it returns null. The $session->login might also be a good one to hook if you don't want to create your own login form. I think this would be preferable to trying to hook in ProcessLogin or ProcessHome.

It should be possible using the ProcessPageListRender::getPageLabel hook. That function is given a $page as an argument, and it returns the label to use for the page in the page list. If you hook in after it, or hook replace it, you should be able to have it return an <img> tag instead. This is something we may want to add to the core at some point too, but based on a quick look, it appears that a module could accomplish it pretty easily.

Someday we'll definitely have to have ProcessWire US meetup. Atlanta seems to be pretty quiet from a web development community aspect. I've been here for 9 years and don't know any other web developers around. On the other hand, Atlanta has the world's busiest airport and a worldwide air traffic hub of sorts (i.e. easy to get to). Still, I think if folks are traveling by air then it's better to combine it with a larger conference to maximize the value for everyone. For instance, an interactive conference like SXSWi in Austin, TX or something a little smaller. So there would be a ProcessWire meetup, but within the context of another related conference. I think that would be the ideal way to go for a US meetup since everything here is spread out a lot further than in Europe. I'm guessing it's a lot easier to have a dedicated meetup in Europe because things are closer and transportation options are much better (trains, etc.).

If it doesn't add any overhead, or interfere with anything existing, I'm cool to add it in the core as one of those things people can choose to optionally turn on. I think if I could see a diff or GitHub pull request that shows me what's different, that's all I'd need. I still don't really understand the Bramus CSS extras plugin or know how/why/when to use it, otherwise it would already be added. For instance, their "what is bramus css extras?" screen implies that one can't float images without it (which obviously isn't true), among other things. I only get lost in their demo, which seems to cross some uncomfortable boundaries of turning TinyMCE into a styling tool. So I've always been a bit perplexed by the value of this plugin. However, I do understand that it is apparently very useful, as many don't want TinyMCE without it. So if it makes life easier to have it as an optional component in the core, lets add it.