ryan

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.

For YouTube, you would actually be adding "&rel=0", not "?rel=0", i.e. https://www.youtube.com/watch?v=Wl4XiYadV_k&rel=0 This works here. Is it possible that you used '?' rather than '&' ? If not, please post the exact URL that doesn't work.

That's correct that the 1% is taken out and substituted as left margins instead. This is for all columns except for the first in a row. I've actually been planning to switch to width classes rather than the inline styles that are used now. The primary reason is just to be able to support breakpoints with responsive layouts. For instance, if you've got a screen width under 600 px or something like that, you might want to cancel the floating behavior of all widths less than 100%, and instead just make them take up a full row. We can do that if we're using classes, but not if we're using inline styles. @interrobang: Check the markup settings in the Form Builder module settings. This may let you add the extra wrappers you want. Also want to mention that just because Zurb Foundation or Bootstrap (or another) provide some form features and grids doesn't mean that you have to use them with Form Builder. I personally think you are a lot better off with Form Builder's defaults than you are with those of Foundation or Bootstrap. Those frameworks are just trying to cover common form needs for the masses, but Form Builder goes well beyond this. As soon as you start letting a general purpose CSS framework take over your form styling needs, you are then limiting Form Builder's output capabilities to those of your framework. Though if you are dealing with fairly basic forms (primarily text fields) and simple needs, then there's also no harm in using a CSS framework for form styling either. But I think you will be happier if you give this control to Form Builder rather than [insert CSS framework here].

Digitex, I think I found the issue. Please try the latest update and it should work now.

$user = $users->get('antti'); $users->setCurrentUser($user); If you want to make the user persistent for the session (without having to do the above on every request), then do this: $session->_user_id = $user->id;