ryan

Welcome Frikki! I think you are the first person here from Iceland (?). Hope that you enjoy using PW. Let me know if you are ever interested in making an Icelandic language translation pack.

This is awesome Antti! Nice work!

I totally agree it would be great to have a modal dialog that then creates pages and all their fields. But there is a rather large difference in development time between that and what I've added. I added what I could afford to in the short term. Down the road, I'm sure we'll expand the capability to take the modal route when dealing with creating pages that have more than just a title field. But since I could add the title-only page additions in the short term, I figured that's a good place to start. Even when we expand with the modal dialog, I do want to keep the current method for when the template has just a title field. The reason is that this is a very convenient way to create large selects. Lets say you need a "country" select -- you can paste all 196 countries into that field and create all your select options in one shot.

You can do it like this: $num = count($comments); $options = array('headline' => "<h3>$num Comments</h3>"); echo $comments->render($options); See here: You could edit the module and remove it, but I don't recommend doing so. The email field is not displayed to anyone, it is just used as a way to recognize when a comment is made by someone that already has an approved comment (so they don't have to wait in a moderation queue). If you were certain you didn't want it, you could always pre-populated it with some fictional address and hide it with CSS.

When you are dealing with API functions, you aren't dealing with markup. You are only dealing with markup when you create and output it yourself. I think this may be what you are looking for? // .. starting in the middle of your example: foreach($children as $child) { $class = $child->id == $page->rootParent->id ? " class='on'" : ''; echo "<li><a$class href='{$child->url}'>"; if($child->id == $homepage->id) echo "<img src='your image file' />"; echo $child->title . "</a></li>"; }

Required fields aren't actually supported in the system at present. While some fields may support them on their own, they are only accessible in advanced mode and that is intended just for ProcessWire development (not for site development). But when the system supports required fields in a near-future version, that will of course be accompanied by appropriate labeling, etc. However, I don't recommend using required fields at present because they've not been tested for use outside of very specific things in the admin.

I think that ideally you would maintain a separate template for each of those sections, but I understand what you are saying that it may be more hassle to do that. I am interested in updating the CustomPageRoles module to go much further than it currently does, but that's down the road a bit. But I think it would be possible to create a module and hook after Page::editable (like CustomPageRoles is doing with Page::viewable). Your section template should enable access for all the roles that have edit access to any given section. But then your custom editable() function will remove that access when they aren't in the right section. You'll create a new role that has the same name as the section page, and then assign that role to the users that you want to be able to edit that section. Then you'd create an autoload module with logic like this: public function init() { $this->addHookAfter('Page::editable', $this, 'editable'); } public function editable(HookEvent $event) { $page = $event->object; // if this isn't a section template, or user is superuser, no need to check further if($page->template != 'section' || wire('user')->isSuperuser()) return; // if they had no access at the template, then no need for us to check further if(!$event->return) return; // we assume not-editable, until proven otherwise $editable = false; // get a role that has the same name as the section page $role = wire('roles')->get($page->name); // if the role exists, the user has the role, and the role has edit permission, then it's editable if($role && wire('user')->hasRole($role) && $role->hasPermission('page-edit') { $editable = true; } $event->return = $editable; }

I took a look at the code block where this comes from. Does it halt the installation? (I'm guessing not). Assuming it doesn't, and the error doesn't appear any more after this, then you should be able to safely ignore that message.

Beautiful site Alex! Great work. Thanks for the ProcessWire mention in the footer too.

I don't think any of us like pagebreaks for these kinds of things. But the reality is that the folks in the marketing department like that one article can generate 4 pageviews (for instance) rather than 1. And we sometimes have to meet the needs of marketing whether we like the result or not. ProcessWire should be flexible enough (and hopefully is) to accommodate needs like this.

I agree with the value of GitHub here. But GitHub is not necessarily a simple thing for everybody. I was intimated by it for a long time (and still am in some ways). So I don't want to have a GitHub requirement that would dissuade any would-be translators. Still, for those that are comfortable with it, it's hard to beat for this sort of thing.

I've never seen a .jpe image myself. I'm guessing it comes about when another system encounters a .jpeg, only supports 3 character extensions, and truncates it to .jpe ... like in the old MS DOS days.

I like that approach. I think that's something we'll probably want to offer as a config option in the future.

Any chance that it might be a 'file' rather than 'image' field? That would explain the lack of a size() function.

Default values are something we'll likely have at some point, but I'm a little conflicted about it. I like the idea that when you create a new page and assign no values to it, it doesn't place any values in the database. There's a clear distinction between set and not set. There's a nice simplicity to that. So I translate that to the way I name and use fields. If I have a checkbox that I want to enable some behavior, I'll name it toggle_behavior and if I have a checkbox that I want to disable some behavior, I'll call it toggle_no_behavior or toggle_disable_behavior. You end up with a smaller and faster database if you are naming and using fields in a manner that veers towards the empty state being the more common one, and assigning any defaults at runtime rather than storing more duplicate 'default' values in the database. But I also recognize that these benefits are more technical than functional, which is why I say we'll likely have them at some point.

Thanks for the updates Soma, the theme works beautifully.

Soma, the code we're using right now to find the upload temp directory is this: $dir = ini_get('upload_tmp_dir'); if(!$dir || !is_writable($dir)) $dir = sys_get_temp_dir(); sys_get_temp_dir() is only used as a fallback if the system has no defined upload_tmp_dir. I would think that if a host were to be using open_basedir() they should at least set an upload_tmp_dir in their PHP, or at the very least, allow you to set it (with a site-specific php.ini or something). It seems like their PHP settings may be set to discourage use of file uploads. Here's a couple of related threads: The error you are getting with the $_ENV['TMPDIR'] indicates that there's no value set for TMPDIR. So your realpath() call is very likely operating on the value NULL and returning the web root (which may be writable, but not desirable). --- Edit: just added a new $config->uploadTmpDir that you can set in your /site/config.php. This will override PHP's upload_tmp_dir for ajax uploads only (I don't think we can override that on non-ajax uploads). I recommend creating this dir: /site/assets/uploads/ Then add it to the disallowed directories in your .htaccess file. Basically add it in with the other assets dirs like cache and sessions. Then update your /site/config.php: $config->uploadTmpDir = dirname(__FILE__) . '/assets/uploads/'; Now see if it works?

Thanks for finding this Diogo. Looks like I missed the ui-helper-clearfix class when the last inputfield in a form was reduced width. This has been fixed in the latest commit.

Sorry guys--looks like a bug, thanks for finding it. Just fixed this in the latest commit. When you get a chance, please confirm that it fixes it on your end too.

Soma, try setting PHP to use a different upload tmp dir, from your /site/config.php ini_set('upload_tmp_dir', dirname(__FILE__) . '/assets/cache/');

Nice job, thanks Jacmaes!

Soma, send me the phpinfo if you can. I'm wondering about any safe mode or open basedir settings.

Biotech, I agree with the idea to use a '#pagebreak#' tag or something like that. In your template your code would look something like this: $pageBreaks = explode('<p>#pagebreak#</p>', $page->body); if($input->pageNum && isset($pageBreaks[$input->pageNum])) $body = $pageBreaks[$input->pageNum]; else $body = $pageBreaks[0]; echo $body;

32k-64k is way too small a limit for PW site. I like to think PW would be happy up to a million or more pages. So will have to make sure the file system isn't interfering with the scalability. It seems to make more and more sense that we don't keep empty directories.

This is correct. My own sites depend on it.