ryan

This feature is now available in the latest commit. Please let me know how it works for you guys. You will see a new checkbox option available with page reference fields when editing them under: Setup > Fields > Edit: [your-field] > Input [tab] > "Allow new pages to be created from field?". It includes instructions on the required settings for it to be active.

The field-template context is now committed to the source, so it is ready to use. Please let me know how it works for you guys. You can access it from any template or repeater field by clicking on a field name in the asmSelect list. When you first add a new field to an existing asmSelect, the context option isn't yet available. You have to save the template before you'll see the option to alter its context. When editing a field (from Setup > Fields), you will also see a context pulldown in the upper right corner. This is just a shortcut when/if you want it. -- Edit: you may need to hit 'reload' in your browser once or twice if you aren't seeing the field context option at first (old files may be stuck in cache).

I also wanted to add that some other major updates were committed this morning (template field context, page inputfields that can add pages, and some other minor things). In order to add the template field context, I had to make a small schema change to one of the tables. This happens automatically on the first pageview. However, because a change is being made rather than rendering that first pageview, you may see an error. Don't be alarmed. Just hit reload/refresh in your browser and all should be good. Like with all updates, it's a good idea to backup your DB and files before installing or pulling it in.

The GitHub repo was just renamed from P21 to ProcessWire. For those that are pulling from this repo, you'll need to update your remote origin. To do that, type this at the command prompt in your PW installation: git remote set-url origin git://github.com/ryancramerdesign/ProcessWire …or this (apparently required for older versions of Git): git remote rm origin git remote add origin git://github.com/ryancramerdesign/ProcessWire If you are using a graphical client for Git, then I'm sure it's just a matter of clicking to a 'remote origin' setting and replacing the P21 URL with: git://github.com/ryancramerdesign/ProcessWire Thanks to Robert Zelník for the instructions on how to do this.

The 'created' field is set from a MySQL 'NOW()' command (current timestamp), rather than from ProcessWire or PHP. I would guess that your MySQL may be configured for a different timezone? I've not seen this difference before. Try this in a MySQL client (like PhpMyAdmin): SHOW VARIABLES LIKE '%time_zone%' Based on your NY timezone, it should say this: system_time_zone EST time_zone SYSTEM

You can put it in a separate template or keep it in the same one. If you keep it in the same one, then you'll want to trigger the RSS feed from a URL segment or a get variable, i.e. if($input->urlSegment1 == 'rss') { $rss = $modules->get('MarkupRSS'); // rss output } else { // non-rss output } // or if($input->get->rss) { // rss output } else { // non-rss output }

I had an hour to investigate both and select one for a client project I'm working on. I picked HTML Kickstart. Twitter Bootstrap looked great, but also made me think I'd need a couple days to get up-to-speed with it all... making me wonder if it would save me time over starting from scratch (which is what I usually do). Whereas HTML Kickstart seemed more accessible to get going immediately and save me time. If I needed the responsive layout for this particular project, I might have chosen differently. I also look forward to using Twitter Bootstrap in more depth hopefully soon too. But HTML Kickstart seemed to me like it has the better balance that would motivate one to use a framework like this in the first place--a time saver in every respect. Quite impressive what Joshuag has done with this. I hope to have PW profiles for both at some point.

Thanks for the feedback everfreecreative. We were on opensourcecms.com for a couple of months, during which time we gained several hundred positive votes and hovered around the first page, often in the top 3. Then one day, we suddenly had 2,000+ negative votes in less than 24 hours. We figured out how the results were being manipulated. I contacted the owners of the site to notify them what had happened and show them how it was being done. I also asked them to remove PW from the site until they could correct the issue. They did apologize, but the issue remains. Joomla is a good barometer--if it's showing up in the top 3 "best rated" then you know something smells fishy. ProcessWire is not the only CMS missing from opensourcecms.com. Some of the best projects out there have intentionally disassociated from this site for similar reasons (Symphony is another good example). I know the site is under new ownership (apparently a group involved with typo3), and I'm still holding out hope that they will take the responsibility seriously. I would like to get PW there again, but not till the problems there are fixed and they are there to support open source rather than exploit it. (that statement is specific to the old ownership). I noticed they launched a new design, but with the same core problems in place. But change takes time and I remain hopeful with the new site ownership.

This looks like an interesting service. While I'm not sure I understand where the value would be for a low traffic site, it seems like it would be a great way to equip a site to better handle traffic spikes and provide faster regional performance... especially for sites that deal with higher traffic. I like that entry level CDNs are getting to be commonplace and within reach of all of us.

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.