ryan

You are too kind Teppo. I'm no ninja on that front -- I break as much stuff as I create. But I do try and account for that as much as I can... if I've been adding stuff that I know has potential to break things or result in any potential behavior change, I put it in the dev branch. If I'm adding code contributed by others, I'll put that in the dev branch. But if I'm updating stuff that is unlikely to break anything for anyone (especially bug fixes), then I'll put it in the master branch. Once I've been running on the dev branch myself for awhile without issue, then I'll try to get some other people to test it out, and if all is good, it gets merged into the master (along with a minor version number bump). I still consider myself kind of a novice with GitHub, so am slowly learning the right workflow here. But as time goes on, I hope to be using as many best practices here as possible. So far I've not been using the dev branch when it comes to more minor stuff. If I don't have something big going on (i.e. stuff that needs more testing), then I'm not really using the dev branch. But I will try to be more consistent with a consistent workflow that predictably goes from dev to master. This isn't the way it should be, it's just me not being a Git expert yet. I'll use a more consistent workflow here, especially now that I know people are looking at the dev branch.

Probably not ideal for really large sites as it clones the /site/assets/files/ directory in creating the profile (which may double the size of disk space used by your site, temporarily). I could add an option to the profile exporter that justs instructs you which directories to download into your profile, rather than copying them. That would make it more useful for large exports. But the profile exporter was originally meant for doing things like exporting the Blog Profile or migrating a new site, as opposed to functioning as a dedicated backup tool.

Definitely moving forward with files fields as soon as possible. But saving to pages doesn't make it an easier prospect only because saving to pages is an option, not a requirement. Most people don't need to save pages and I don't want that to be something you'd have to do in order to get file fields. So I'm still planning on developing these file fields independently of the ones already included in ProcessWire. Though it's always possible I might modify the ones we've got to change the behavior to a broader context that would be inclusive of Form Builder too.

Another update: Form Builder 0.1.5 (the current version) now supports Auto-Responder emails and customizable email templates for both admin emails and auto-responder emails. -- Edit: WillyC somehow I messed up your message. I think I clicked on edit rather than reply when i was trying to post (I probably shouldn't be a moderator) . Can you post again? (sorry)

Sounds like another keyword I need to add to the reserved words list. Somehow missed that one before. You can use upper/lower if you want to, but they still do get represented in the database as all lower. Meaning, you couldn't have one field named "helloThere" and another named "hellothere".

This is something I don't know much about. But since it's a common law trademark and in process of becoming more formal, it sounds like I'm supposed to oversee usage somewhat. Not something that I want to do, but apparently that's the rule required to protect the name and ensure some other project doesn't take it from us. So probably best to consider it in the same vein as another CMS logo like Modx or Drupal or something. Meaning you'd avoid using it (without permission) in situations where it might imply that the brand is endorsing or promoting something that it isn't. So if there's any question about something you want to do with the logo, then probably best to contact me about it, just to play it safe. I'm sure it'll be fine, but that way at least we can say we're following the rules, and have the right documentation necessary to protect the name for the ProcessWire community. So far I'm loving all the ideas too (particularly the hot air balloon)

has_parent only works with 1 page because the only reason it exists is to provide the Page::find() capability -- or at least, that was the original intention. I'm not sure what the structure you have is exactly, but you can use "|" with parent. So if you could narrow it down to the parents, then you could do it. Something like this might provide an equivalent functionality, though not ideal if the potential number of parents is huge. $parents = new PageArray(); $hasParents = $pages->find("id=2293|1038"); foreach($hasParents as $hasParent) { $parents->add($hasParent->find("num_children>0, template!=picture")); } $selector = "template=picture, sort=-created, limit=20, parent="; foreach($parents as $parent) $selector .= $parent->id . "|"; $photos = $pages->find(rtrim($selector, '|'));

This sounds like it'll be a nice module! I look forward to checking it out (if this is one you'll be releasing).

If we could assume just a superuser environment, then we could narrow the scope and make it more convenient for that specific scenario. But since we are a multi-user, multi-access environment, we can't make those assumptions. Like you correctly noted, using 'hidden' would only be a good idea if you were dealing with non-sensitive stuff. And of course, 'hidden' isn't specifically meant for this purpose in the first place. Using access control with your WIP tree is a good way to go. It would also not be much of a stretch to implement your own unpublished feature to work however you want it. You would add a checkbox to your template called something like 'toggle_unpublished'. Then in your head.inc or whatever initial/common template your site uses, you would just check for that first: if($page->toggle_unpublished && !$page->editable()) throw new Wire404Exception(); Combine that with the hidden status (to keep it out of navigation), and I think you'd have exactly what you need. If you didn't want to have to bother at all with the hidden status, then you could update your find() or children() selectors to include "toggle_unpublished!=1". Or if you didn't want to even bother with that, you could make a hook function to do it for you (at the top of your head.inc, before output has started): $pages->addHookBefore('find', null, 'hookPagesFind'); hookPagesFind(HookEvent $event) { $event->setArgument(0, $event->arguments[0] . ", toggle_unpublished!=1"); } All page get/find/children/siblings/etc. calls get routed through $pages->find, so you wouldn't need more than this 1 hook.

Well, technically it's a double-handled ProcessWire-engraved beer stein, but you can also use it for coffee too if you want.

Michael van Laar was kind enough to make a vectorized version of the ProcessWire logo with several variations, and he sent them to me. This is the first time the PW logo has existed in a vectorized format. Now I'm thinking I need to have some coffee mugs, hats, t-shirts, or airplane banners made. Attached is a ZIP file of the logos he put together, in case anyone wants them to make their own "powered by ProcessWire" banner or anything like that. This will probably become part of a more formal media kit at some point. ProcessWire-logo-michael.zip

I don't know about the syntax error... this is the query you originally posted, but I just changed $userID to $user->id. You might get rid of the `backtick` characters as they really aren't necessary. If this is a ProcessWire-created table, then the page_id field would be named pages_id (plural). But I don't know your table schema. If it's not a MySQL syntax error, then you might change $pages to wire('pages'), as $pages would only work in template scope. For pagination, you'd want to do that in your your SQL query. Here's an updated example that uses pagination: $limit = 25; $start = (wire('input')->pageNum - 1) * $limit; $sql = "SELECT page_id FROM field_favorite WHERE created_user_id=$user->id LIMIT $start,$limit" $result = wire('db')->query($sql); $ids = array(); while($row = $result->fetch_row()) $ids[] = $row[0]; $template = $templates->get('product'); $fav = $pages->getById($ids, $template); Btw, if 'favorite' is by some chance actually a ProcessWire field you've created, you really would be better off just doing this: $fav = wire('pages')->find("template=product, favorite.created_user_id=$user->id, limit=25"); --- edit: I think the syntax error must have been my use of list() before (just realized). Fixed in the above example.

Thanks Steve! That's very kind of you. What you may not know is that I've been raising my beer glass to all of you this whole time. Here's the rest of my profile photo

You could also do this: $result = wire('db')->query("SELECT `page_id` FROM `field_favorite` WHERE `created_user_id` = $user->id"); $ids = array(); while($row = $result->fetch_row()) $ids[] = list($row); $fav = $pages->getById($ids); Or, if 'favorite' is a ProcessWire field (which you maybe added a 'created_user_id' column to the table), you may be able to do this: $fav = $pages->find("favorite.created_user_id=$user->id");

For sites without a lot of fields, I think that adding a groups designation would just be confusing, at least for new users. So would ideally like to find something that you don't really notice until you are specifically looking for it. How about if the field's 'advanced' tab had a text input where you could enter one or more tags? When used, the fields list would include a list of tags in use at the top, and clicking any one of them would make the list show only fields with the clicked tag.

jukooz, I tried to duplicate this by putting a checkbox in a repeater, but can't seem to duplicate it. However, a few recent commits have made modifications to the checkbox inputfield (even within 2.2.9), so you may want to grab the latest from GitHub, just in case…

1. What is running in the root folder of the domain? If it's also ProcessWire, you might want to use one of the multi-site support options. 2. You could try modifying $config->urls->root at the top of your template file (like Soma suggested): $config->urls->root = '/'; You'll also want to setup these two symlinks in your web root: /site/ => /annemieboer.nl/site/ /wire/ => /annemieboer.nl/wire/ I haven't tried this, so keep an eye out for adverse effects. 3. I think option 2 would be the simplest. But if for some reason that doesn't work, another option would be to hook Page::render. AdminBar is a good example of a module that does this. public function ready() { if($this->page->template != 'admin') $this->addHookAfter('Page::render', $this, 'hookPageRender'); } public function hookPageRender(HookEvent $event) { $event->return = str_replace('/annemieboer.nl/', '/', $event->return); } If you went this route, you'd still want to setup the symlinks I mentioned above.

Yes, if you create a form with Inputfields manually then calling the processInput() method on the InputfieldForm will process and validate the fields. In your case you could do something like the previous example with InputfieldSelect, but you could always populate it with options of $page->id => $page->title or something like that. When you want to specify separate values and labels for options, you just make the array associative. I'll repeat a part of the example above, except modify it to specify separate value and label: $select->addOption('My option group', array( 'A' => 'Option A', 'B' => 'Option B', 'C' => 'Option C' ));

Looks good! Though I think you are probably better off with a solution that doesn't require modifying a core file (but I'll be happy to update the core if you think this is going to have broader usefulness). I modified my previous example a bit, just so that it's a little smarter about when it decides to add the hook (slightly less overhead). Basically, it moves some of the logic out of the hook function and instead uses it to determine whether to even attempt the hook. public function ready() { if($this->page->template != 'admin') return; if($this->input->get->parent_id != $the_parent_id_you_want) return; // only add our hook if template is admin and there a parent_id GET variable with the value we want $this->addHookBefore('InputfieldPageName::render', $this, 'hookRender'); } public function hookRender(HookEvent $event) { // if process isn't ProcessPageAdd, exit now if($this->process != 'ProcessPageAdd') return; $inputfield = $event->object; // if the input already has a populated value (possibly from another hook?), exit now if(strlen($inputfield->attr('value'))) return; // if we made it here, populate the value attribute $inputfield->attr('value', 'the-page-name-you-want'); }

In that case, I think you'd want to hook before InputfieldPageName::render and adjust set the value attribute. I haven't tried this, but think this would work: public function init() { $this->addHookBefore('InputfieldPageName::render', $this, 'hookRender'); } public function hookRender(HookEvent $event) { // if process isn't ProcessPageAdd, exit now if($this->process != 'ProcessPageAdd') return; // if the GET var 'parent_id' isn't the one we want, exit now if($this->input->get->parent_id != $the_parent_id_you_want) return; $inputfield = $event->object; // if the input already has a populated value, exit now if(strlen($inputfield->attr('value'))) return; // if we made it here, populate the value attribute $inputfield->attr('value', 'the-page-name-you-want'); }

I think the best hook might be Pages::setupNew. That function gets a new $page (before its been saved) as the 1 argument. If the page doesn't have a name yet, then that function creates one. So it's the perfect spot for you to assign a name. public function init() { $this->pages->addHookBefore('setupNew', $this, 'hookSetupNew'); } public function hookSetupNew(HookEvent $event) { $page = $event->arguments[0]; if($page->parent->id == $the_parent_you_want) { $page->name = 'the-page-name-you-want'; } }

The Save-to-Pages feature is now available in the current version of Form Builder (0.1.4) posted in the Form Builder support forum this morning. It hasn't had a lot of testing yet, but I believe this feature is ready for people to use so long as you test things out adequately after configuring them, and let me know of any issues or concerns you find. To use it, you click "Save to ProcessWire Pages" on the Actions tab of any form. A fieldset will appear asking you to select a template to use for new pages. Hit save, then go back to this screen. More options will now appear, like this: From there, you choose the parent where pages will be created and setup what fields in Form Builder will populate the Page fields. You also get to choose whether you want the pages to be created manually or automatically. If automatically, then you can set whether they should be published or unpublished. Automatic pages are created at the time the form is submitted. Manual pages are created by you checking a box on the entries screen. Here's what that looks like: You click the checkboxes for any of the entries you want to create pages from and then click the "Send Checked to Pages" button at the bottom. The pages are created immediately. Note the "Page" column in the screenshot above. If an entry has already been sent to a page, then this column will be populated with the ID of the page. If you click on it, it'll take you to that page. Should you re-send one of those to a page, then it will update the existing page rather than creating a new one.

The InputfieldSelect does support optgroups (for your self generated selects), but InputfieldPage doesn't use them. So to do what you are wanting there, you'd probably need to make something custom. To make option groups with InputfieldSelect, do them like this: $select = $modules->get('InputfieldSelect'); $select->attr('name', 'name_of_select'); $select->addOption('My option group', array('Option A', 'Option B', 'Option C')); $select->addOption('Another option group', array('Option 1', 'Option 2', 'Option 3')); $select->attr('value', 'Option B'); // example // render here, or add to an InputfieldWrapper/InputfieldForm/InputfieldFieldset echo $select->render(); Another route that you could use now would be to just title your selectable pages in a manner that reflects the group, i.e. "Course: Edition A" rather than just "Edition A".

I'm not sure that I've got enough knowledge these apache directives or this compression to say for sure, but it seems like it's basically saying to compress all requests that have the indicated content-type headers. Since ProcessWire would be delivering type "text/html" it seems like that would work. But maybe Apache only does this if the request is to an actual physical file or something? You might try this shot in the dark: add a content-type header call to the very top of your template file (before any output): header("Content-Type: text/html"); If you actually need to perform the compression yourself, then that would also be possible to do by hooking after Page::render, compressing the markup in $event->return, and then stuffing it back into $event->return. However, I'm still thinking that it seems like we should be able to get Apache to do this for you... just a matter of determining how. I have a feeling someone else here will know how to do this.

All fields need to function in the same namespace, so if we did something like this, it would be just for visual benefit in the admin. But I still think it would be worthwhile.