ryan

Nico, guest should already have access to it. That's actually the reason for this module: to bring what was previously an admin-only available service to the front-end/public side. View your /service-pages/ page when you are not logged in, and you should be able to test it as a guest. Let me know if you are unable to access it as guest?

@Lars282 Soma and Slkwrm have it right. Keep in mind that saveReady is called after it's been confirmed the save() will definitely occur, and right before the save actually occurs. So this is the ideal hook for you to use in your case. This is correct. We don't yet have a property $page->statusPrevious property like we do for parent or template. So there's no way for you to know what the previous status was short of loading another copy of the page, or just querying the database like in the example. But now you've got me thinking I may need to add a statusPrevious property in a future version. For your hook attachment code, I would suggest this: public function ready() { $this->pages->addHook('saveReady', $this, 'sendMailOnPublish'); } …basically the same as what Soma suggested, except that I would add it to $this->pages directly since there is only ever 1 instance of $pages, making it slightly more efficient to do this way. Your actual hook function will be in the same class as your ready() function, and would resemble the one Soma posted. This is correct. If there was no $page->id, it would be a new/unsaved page, and you wouldn't want to go querying the DB for it as we know it wouldn't be there. So that's what the $page->id check is for.

One minor question on the install update. I like that you've added the PCRE UTF-8 support check (nice!), but wondering if there's some way we can accomplish it without changing the encoding of the whole install.php file to UTF-8? The reason I ask is that once I pull the file into VIM, it's converting this line: if(! @preg_match('/^.$/u', 'ñ')) { to this: if(! @preg_match('/^.$/u', '√±')) { which would break it, once I hit save.

Thanks for this SiNNuT! Posting here is just as good as GitHub, doesn't matter to me. I will pull this into the dev branch and look at the changes and test, etc. Thanks again for these updates.

I don't have a simple solution to this one, but will do more thinking about how I could have ProcessWire provide a hook like Pages::statusChanged or something like that. But until we have something like that, here are a couple ways you could do it: Option 1 Add a hook to Pages::saveReady and have your hook function do something like this: Pages::saveReady hook $page = $event->arguments[0]; if($page->id && $page->isChanged('status') && !$page->is(Page::statusUnpublished)) { $result = $this->db->query("SELECT status FROM pages WHERE id={$page->id}"); list($status) = $result->fetch_row(); if($status & Page::statusUnpublished) { // page is about to be published // send your email } } Option 2 The other option would be to change your workflow such that user submitted pages went into a different parent than the live ones. For instance, user-submissions might go into parent /pending/ and published submissions would live in /live/. Then you could have your hook monitor for when a page is moving from /pending/ to /live/. If you wanted to, you could also have it take care of the publishing automatically: Pages::saveReady hook $page = $event->arguments[0]; if(!$page->parentPrevious) return; // if page is not being moved then stop now if($page->parent->name == 'live' && $page->parentPrevious->name == 'pending') { $page->removeStatus(Page::statusUnpublished); // send your email }

I think that's probably a question for the developer of the commercial template that you bought. Since you apparently bought a non-restrictive developer license, then it sounds good on the surface. But Pete is right that nobody can answer this without actually seeing the license and looking for some kind of language that says you can release your stuff to the public as open source. My best guess is that the developer license probably allows what you want to do, but it would be good to make sure.

This is really great, thanks PawelGIX! I took a look over the code and it looks nicely put together. I could only test on localhost this morning, but it understandably does not work there since the Pixlr service needs to operate on a web-accessible image that it can read from. Still, I got a feel for what it does and how it works and must say I'm impressed. I can't wait to try this on web server… it seems like a great capability to have, and I really like the way you've integrated the buttons and service. Only possible suggestions I have are: 1. Maybe move your hooks from init() to ready() and check that $this->page->template == 'admin'; before adding the hooks. Not really necessary, but would be slightly less overhead if the hooks aren't attached when they don't need to be. 2. Maybe rename on GitHub from 'processwire-pixlr' to 'PixlrEditor' (or 'ProcessPixlrEditor') so that people can 'git clone' and not have to go back and rename the directory in order to install. Again, not really necessary, but might make it quicker for some to install. 3. Post it in the modules directory! http://modules.processwire.com/add/

closestParent() makes the most sense to me. Though I'm still wondering about just: parent($selector); because the parent() function already implies closest parent (given that it returns the direct parent of the page). So if you provide a selector to it, then it's like saying: "closest parent that has [something]." I also like that extending the existing parent() function in this way wouldn't involve adding a new function to the API. It would also make it consistent with how the child($selector) function works. jQuery uses parent(selector) for something that isn't applicable to ProcessWire. jQuery's parent() can return multiple items, and the selector filters those. So they didn't have a choice to use the parent() function for this purpose. In our context, we don't actually need a separate function like they do.

I love the forum software here, but agree the code bug is making me a little insane. I'm tempted to try and go in the code and fix it myself, but wouldn't know where to start. If IP.Board would just replace their rich text editor, I think they'd have a near perfect product. The rich text editor bugs in IP.Board only seem to mutate and evolve… they fix one thing, and break another. But I kind of understand, as TinyMCE in ProcessWire is no different in this regard… fix one thing, break another, rinse, repeat. Rich text editors are just plain complicated and evil (though a necessary evil). But the world would be a better place if we all used lightweight markup languages instead. The only other consistent problem I run into is that I my "View New Content" button (that I depend on) often completely misses some things. And I've lately had an issue with PMs showing up in my list, days after they were sent. Though I'm also getting old and sometimes wonder if I'm the one missing things, as the IPB behavior seems very random. So if anyone has ever been expecting a reply from me and didn't get it (whether in the forum or PM), let me know (email ryan at this domain), as it's very possible I never saw it.

This all makes sense, I'll plan to get the closest() method added. The only thing I'm having a little trouble with is the term "closest", as to me it would imply not just parents, but siblings, children, etc. I realize it's just referring to parents in jQuery, but still question their choice of the term. Would it not be better for us just to support a $selector argument on the parent() method, like $page->parent($selector)? Seems like it would do exactly the same thing, but maybe be a little more readable? Maybe I just haven't used this particular method in jQuery enough. But I like the goal behind the closest() method, regardless of what we call it. I tend to use rootParent quite a lot in my own sites, for any number of things. But then again, all my sites are structured in a manner that the first level pages are always the main section pages… and that never changes. So rootParent and me are good friends.

Great ideas. Anyone want to do a pull request for this? Either way, I'll plan to get these updates in 2.3.

Is this what you think happened in the case you mentioned? I can't say as though I've witnessed that behavior, but let me know if you are able to reproduce the redirect loop--it seems plausible in the situation you mentioned. 301s are useful, but 302s can also be dangerous if used in the wrong place. I was stating this just to clarify why 301 is the default behavior of the $session->redirect function, and why you have to specify a second bool param if you specifically want a 302.

I'd be surprised if your IP is changing that often on a cable/DSL setup. If it were going through some wireless service, then it might be more likely to change often. Session fingerprinting also looks at the user agent string... is it possible anything is changing in that? (some browser plugin changing it or something)?

If you are in control of IT, why are you even using IE??

Repeaters are still pages, but I agree with what you say: content that needs to be moved around a lot will be more accessible outside of a repeater.

Can you clarify what you mean by add your extension to the "~"? I'm not sureI understand.

What might be good is if we just add $selector support to the $page->parents() function so that you could do: $page->parents($selector). Though, keeping consistency with jQuery, adding closest() might make sense as it returns a single item rather than an array (as parents() would). I'd never used closest() in jQuery before, but this page describes the difference (scroll down a bit): http://api.jquery.com/closest/ … I think it seems like a good idea.

This nearly always points to the server not reading the .htaccess file or not having Apache's RewriteEngine. Try adding some random characters to the very top of your .htaccess file, like "hello321" and save. Try to load your homepage. If you don't get a "500 server error", then the server is not reading your .htaccess file. I think this is the most likely scenario and if you find it to be the case, you'll need to ask the web host to enable .htaccess support. Let us know what you find?

We've never seen any negative side effects from using 301s, so that became the default behavior of $session->redirect(). Whereas, there can be negative side effects from using 302s on the front-end of your site (at least with regards to Google). Even if that reason doesn't matter on the admin side, most redirects that PW does internally I would still call fitting the permanent designation, semantically. Though if a browser/software did start applying that literally to just a URL in our context (as opposed to a URL+POST) then we'd be forced to use 302s in some instances. This one might make more sense as a 302, I agree. I've not seen this before, but please let us know what you find.

Good ideas Ralf and Slkwrm. I've added a Language Packs link to the main ProcessWire download page. We may go further with some of these ideas when there is time too.

If you stick with the way you are doing it now, giving each checkbox field it's own 'name' attribute, then you would just need to update your $form array to include them, like the additional 'Hats' entry below: $form = array( 'contact_name' => $sanitizer->text($input->post->contact_name), 'email' => $sanitizer->email($input->post->email), 'comments' => $sanitizer->textarea($input->post->comments), 'Hats' => ($input->post->Hats ? 'Yes' : 'No') ); Your <input> tag should also read like this: $checked = array(); $checked['Hats'] = ($form['hats'] === 'Yes' ? 'checked' : ''); … <input type='checkbox' id='Hats' name='Hats' value='1' $checked[Hats]> However, I think a better way to approach all of the above is to use just one $products variable to account for all of them. $products = array('Hats', 'Gloves', 'Mens', 'Bags', 'Scarves', 'Clothing'); $form = array( 'contact_name' => $sanitizer->text($input->post->contact_name), 'email' => $sanitizer->email($input->post->email), 'comments' => $sanitizer->textarea($input->post->comments), 'products' => array() // make it an empty array ); // sanitize like this if($input->post->products) foreach($input->post->products as $product) { // here we are just ensuring submitted products are in fact valid if(in_array($product, $products)) $form['products'][] = $product; // add product } // output the checkboxes like this: foreach($products as $product) { $checked = in_array($product, $form['products']) ? "checked" : ''; echo "<label><input type='checkbox' name='products[]' value='$product' $checked> $product</label><br>"; } The above may look longer, but keep in mind it's replacing the entire checkboxes input and output, while giving you more flexibility. Adding a new product is just a matter of adding it to the $products array at the top. When you generate your email, you'll want to detect the array so that the email has the product names rather than the text "array()": foreach($form as $key => $value) { if($key == 'products') $value = implode(', ', $value); // make it a CSV string $message .= "$key: $value\n"; }

If you clone the page with the repeater, it should make a copy of the repeater items as well. But if you need to take that repeater and literally put it on another page, then ask yourself: is this a one-time thing, or something I need to do multiple times? If multiple times, then consider adding a page reference field so that one page can opt to choose the repeaters from another, rather than maintaining duplicate entries across pages. But if it's just a one-time thing, then I don't have an easy answer outside of using the API to do it.

Using your existing example, you could do it this way, which is a little simpler and less code. Basically you'd just add your own 'totalPages' temporary variable to each category… and use that in your output. That way you don't have to retrieve those categories any more than once (it would execute faster too). $categories = $pages->find("template=kom_catlanding"); foreach($categories as $category) { // populate your own made-up variable: totalPages $category->totalPages = $pages->count("template=kom_project, project_services=$category"); } echo "<ul id='catcloud'>"; foreach($categories as $category) { echo "<li><a href='$category->url' class='$category->totalPages'>$category->title</a></li> } echo "</ul>"; If you wanted to sort them by count or something, you could do this: $categories->sort('-totalPages'); // sort most to least

That sounds like one possible way to do it. But maybe not ideal unless you are already having them fill these things out on the front-end. You could always create a custom Fieldtype/Inputfield designed for this specific purpose. But if you are okay with the information being automatically populated when the page is saved, you could pretty easily create a module to do it for you. Such a module hooks before Pages::save() and looks for pages having the expected fields, then automatically populates the required value, before the page is saved. Let me know if I can describe further or give an example?

I'm not familiar with this architecture, but wanted to mention that ProcessWire doesn't need DB create privileges. It just needs for you to specify what DB it should use (one that is already created by someone with privileges to do so). If that behavior is annoying, you can also disable it by uninstalling the SessionLoginThrottle module. 180 second timeout is really short: 3 minutes. This could be the entire problem right there. I would suggest bumping that up to 3600 (1 hour). But if that's not it, try these: Try editing your /site/config.php and changing the $config->sessionFingerprint line to false. If that doesn't fix it, try adding this line to your /site/config.php: $config->protectCSRF = false; The only other possibility I can think of is if there isn't enough disk space... or something weird with the cookie domain? (switching between hostnames on same site?). But I'm really thinking this has to do with the 180 second timeout. You may think that's enough, but there is some randomness in how PHP's garbage collection of sessions works, and what their GC settings on the server are and maybe (?) that's causing some unexpected/random behavior here.