ryan

Good idea! Perhaps this could be part of our Showcase forum, or a subset of it.

It seems like both HTML Kickstart and Twitter Bootstrap are both very full featured, just in different ways. Zurb/Foundation is not as full featured as either of those two, though there is a lot of nice stuff in it. I got a chance to experiment with it and liked how simple it makes putting together a responsive site--it seems to be built around responsiveness to the bone. Whereas Twitter Bootstrap has it's responsive abilities disabled by default. The only thing I wasn't sure about with Foundation is the speed of it... it does seem noticeably slower in my browsers than the other two, though that may be isolated to my environment.

Oliver, could I get a copy of the getModuleConfigInputfields function you are using so that I can test with it locally? Feel free to just extract the relevant part and post here or email to me at ryan at this domain name. I just wanted to make sure I'm getting the context of this right.

I think that your best bet for this is your apache log: grep ' 404 ' /path/to/access_log Though that's assuming you are logging referrers in your access log. I also like Google Webmaster tools for finding 404s. You could always create a http404.php template file for ProcessWire, and then have it log the info somewhere: $log = new FileLog($config->paths->logs . '404.txt'); $log->save($sanitizer->text($_SERVER['HTTP_REFERER']) . ' => ' . $sanitizer->text($_SERVER['REQUEST_URI'])); But the above may be overkill since info about 404s is already be tracked in apache logs and web analytics.

Antti, this looks fantastic. I'm pointing another domain to processwire.com so that I can test this out. One suggestion that I have is to change this: // If subdomain is visible on url, we might wanna redirect if(strpos($_GET['it'],$subdomain) !== false) { // We don't redirect if one has editing access (because user would need to login on new domain also) $page = $this->pages->get("/". $_GET['it']); if(!$page->editable()) { $_GET['it'] = str_replace("{$subdomain}/", "", $_GET['it']); $this->session->redirect('http://' . $subdomain . '/' . $_GET['it']); } } …to this (or something like it, as I've not actually tested, but hopefully the intention is there): // saved $_GET['it'], since PW unsets it after using it // note this is an unsanitized variable, so only look at it, don't use it protected $it; public function init() { $this->subdomainsArray = explode("\n", strtolower($this->subdomains)); $this->it = ltrim($_GET['it'], '/'); // ...then your existing code… } public function ready() { // if $this->subdomain was valid in init(), then no need to do more here. if($this->subdomain) return; $subdomain = $this->page->rootParent->name; // if rootParent->name isn't a subdomain, then no need to continue if(!in_array($subdomain, $this->subdomainsArray)) return; // if subdomain is visible on url, we might wanna redirect if(strpos($this->it, $subdomain) === 0 && !$this->page->editable()) { $url = str_replace("/{$subdomain}/", '/', $this->page->httpUrl); $this->session->redirect(url); } } The point of this is to avoid sending an unfiltered $_GET['it'] into $pages->get(), which may contain anything in it at that point. There's always a security concern with sending unfiltered input to any function that isn't expecting it. You can avoid the issue completely by moving the check into the ready() function, which gets called after PW has already validated the URL and determined the page. If you wanted to get more fancy with it, you could also foreach($input->urlSegments) and append $input->pageNum (if > 1), but I really don't think that's necessary.

what? Maybe so, I'll try to split it. I tried creating a new field using the Repeater type, but the label wasn't lost. But I had experienced the issue you describe once before (and fixed it), though not specific to a repeater field. Let me know if you can think of any other details on how to reproduce it. Yep

Thanks Soma, fixed in latest commit.

I was a little worried about making path() or url() hookable since they can feasibly be called hundreds or thousands of times in a request. I found a way to make functions hookable without adding any real overhead, except it requires defining two functions rather than one. But it'll be perfect for high-traffic function calls like this. So I've made Page::path hookable in this manner, and it's ready to go in the latest commit. Note that you'll want to hook the method, not the property. In the Page class, calling $page->path or $page->url resolves automatically to $page->path() or $page->url(), so if you are adding a hook, you want to hook the method. I'm thinking we really only need $page->path() hookable (?), since it is what is used by $page->url(). The only difference between $page->url() and $page->path() is that $page->url() calls $page->path() and then prepends $config->urls->root to it. So $page->path is relative to the PW installation root, and $page->url is relative to the server's web root. Though in most installations, the two are the same, as most don't run PW from a subdirectory. The only other difference is that $page->url() trims off the trailing slash if its template says it should (I don't ever use that feature myself).

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.