ryan

You are right it probably would be a theme job, and certainly doable in that context. As you probably know from the other thread, I don't like any more on the screen than I absolutely have to have at once. So keeping the page list out of the page editor is intended in the default admin theme. But I also understand why many might find it useful to have. Frames may not have a great rep, but that would probably be a good way to look at approaching it, so that the PageList doesn't have to reload on every request. And the editor wouldn't have to run on top of a layer of ajax/js. But there is likely a better way to implement it that I'm not thinking of. I think it would be a great option to have in one our custom admin themes.

I committed the update today that adds a template class to all the PageList items. The class it adds is PageListTemplate_[template name], i.e. PageListTemplate_basic-page. So it should make it possible for modules or admin themes to go further with icons, colors or what not. I don't think we'll be implementing any of this output in the core/default admin theme, but wanted to make it easy for others to add the capability if desired.

Doesn't sound like DB corruption, but there's no way to answer that definitively. You might try disabling those 3 modules just in case, but it seems not that likely that any of them would be interfering here. Can you PM me a link to this site so that I can try to access the URL and see what happens? I'll monitor the HTTP headers to get a little more detail about what could be happening. If you have an FTP login, this would also be helpful to get a look behind the scenes, but that's up to you.

I tried to implement a double click to edit a long while back. jQuery has the dblclick() event, which makes it pretty easy to differentiate from a click() event. The problem is, I never could get it working. dblclick() would never fire for me. It might have just been a bug in jQuery at the time or something. Maybe worth trying again.

I've now used Foundation (2 & 3), Skeleton and HTML Kickstart. Skeleton fits its name in that it doesn't really do anything more than provide the skeleton for a responsive site. It's not what I'd use for a rapid prototype because it still assumes you are going to handle most of the front-end development stuff (and this is one reason why I like it). I was pretty pleased with Skeleton when making the Blog profile, and didn't run into any real mysteries or time sinks with it. Foundation and HTML Kickstart provide a lot more stuff for rapidly prototyping. If you need responsive, then HTML Kickstart is probably out. But if you don't need it, then I would stick with HTML Kickstart. That's because Foundation has a tendency to sometimes fall apart as soon as you throw anything at it. Example: put one too many items in a horizontal nav-bar and it breaks the whole thing. Troubleshooting this stuff sometimes takes longer than if you'd just started from scratch. I don't think that they did much "stress testing" with Foundation. Whereas HTML Kickstart is much more bulletproof and a lot more stuff "just works" without requiring a lot of your time. In addition, it comes with a few more ready-to-use components than Foundation. No doubt that Foundation just plain looks good, but it's kind of fragile. Still, it's got more going for it than not. But out of these 3, if you don't need responsive, I prefer HTML Kickstart.

The subfields on page references update is now committed in the core so that you can do these types of queries (as mentioned above): referenced_pages.title*=$query Also want to mention a limitation: You can't do this with in-memory selection (at least not yet). So the find(), filter() and not() in WireArray/PageArray won't recognize this… just the PageFinder ($pages API var). I'm guessing it'll be awhile before someone even tries it, but just wanted to mention it. I think so. It was a pretty simple matter supporting the subfields of page references, so I think the same would go for parent. I will look into it here more and hopefully get this added soon. Seems like a very nice thing to have. This bug should now be fixed and committed to the core. It sounds like MadeMyDay mentioned this issue too (?), but somehow I missed that message. Thanks to both of you for tracking it down and sorry I missed the message about it the first time around.

That makes sense to me. To add to your list of ways to check, here's another that should be pretty bulletproof: if(strpos($page->url, wire('config')->urls->admin) === 0) { /* hello admin */ }

And would be nice to have Nico add this and his other modules to the directory too (when you have time, of course).

The fact that /abouts/ worked and /about/ didn't makes me think this is browser cache. Can you try from another browser? Sometimes browsers get a redirect cached in there and it's hard to clear. I don't think that you should need anything for your RewriteBase--leave it commented, and try from another computer/browser to see if it does the same thing. Another thing to check is if you have any modules installed that might get involved with redirects, like any of these: http://modules.processwire.com/categories/seo-accessibility/ ... I don't think any should cause problems, but it would be good to know if there were any other factors at play, just in case.

This is really a beautiful site you've put together here! Thanks for posting it.

I agree that type of functionality is very useful. I think that Nico's blog module basically did this. But there is no doubt a lot of untapped potential here, and possibly dedicated tools to use for the import/export of this stuff.

@SiNNuT either here or GitHub is fine. But since we're here, might as well just submit it here. I did commit a few updates this morning, including a fix for the /site/profile/ vs. /site/templates/ typo. I honestly have no idea where I got /site/profile/ from… I need to get more sleep.

I would go ahead and do the redirect that you are talking about. Most likely your output is getting generated before your $page->save(), so the redirect should solve that issue. It also prevents a 'reload/refresh' from re-submitting the form. Basically, there are a few good reasons to redirect after a save, and that's also what PW does in it's admin. You don't necessarily have to redirect to another page, you could just redirect back to the same page, right after you complete the $page->save(), i.e. $page->save(); $session->redirect('./');

You can do this: $cache->removeAll(); If you want to remove an individual cache, you'd want to do what Pete suggested.

The cache is not connected with any page. The only thing that identifies it is the name that you provide for it in the $cache->get('name-of-cache', $seconds); call. It only works for strings. It's intended to cache markup (HTML) per the name MarkupCache. But I don't see any reason why you couldn't serialize an object to a string and cache it with MarkupCache, but you'd have to do the serialization yourself. When the cache is cleared is determined by the duration you specify (in seconds) as the second param to the $cache->get() call. You can also configure it to clear on every page save in the module settings (Admin > Modules > Markup > Cache). There is also a manual cache clear toggle there as well. Modules, templates and core in ProcessWire all use the same stuff, so there's no limits there. You could certainly use it from a module if you wanted to. But get() your cache only when you intend to output it or save it right there, because cache calls can't be nested.

Sure, if it's not any trouble that'd be great. I tend to make changes manually (copy/paste or re-type) from pull requests just so I don't miss anything, but actually having the pull request is a good help thanks to GitHub's very clear diff tracking.

Adam did that page Soma linked to solve your question? There isn't much to the MarkupCache module: just $cache->get('your-unique-name', $num_seconds); and $cache->save($your_markup). Let me know if you have any other questions on how to use it.

if($tagPage instanceof NullPage) { ... } You can also do this to accomplish the same thing (at least, I prefer the syntax): if(!$tagPage->id) { ... } Also wanted to mention that the call to $videoPage->of(true); should instead be $videoPage->of(false). That turns off output formatting for the page, putting it in a save state (vs. presentation state).

From the API you can call the removeVariations() function from any image: foreach($page->images as $image) { $image->removeVariations(); } That actually removes them at the time the function is called, so you don't need to do a $page->save().

I wasn't sure what first what you meant by switcher, but now I think I get it. Assume I understand correctly, you need something to target the switch like a GET variable, i.e. domain.com/?theme=pretty Then before you send any output (like before your <doctype>) you'd check for that GET variable and stuff it in the session. if($input->get->theme) { // set the theme $session->theme = $sanitizer->pageName($input->get->theme); } Now that value in $session->theme will be retained regardless of what page they click on, or at least until they set another. When you get into the <head> part of your document where you are going to be outputting the stylesheet links, you would just check the value of $session->theme: if($session->theme == 'grunge') { $css = 'ugly.css'; } else if($session->theme == 'pretty') { $css = 'baby-unicorn.css'; } else { $css = 'default.css'; } echo "<link rel='stylesheet' type='text/css' href='{$config->urls->templates}styles/$css' />";

This is great Soma, thanks for writing this. I'm finally going to have to try out the GitHub client for Mac myself (I've been just using command line).

This sounds like a bug to me. I'll take a closer look here, thanks for pointing it out.

I would expect to get this error if doing a "continue;" outside of a foreach. Did you place the "continue;" within the foreach? It should have been placed right before the line that has: $r->setOutputFormatting(false); If that still doesn't work, then you can just use an if() instead: if($input->post->submit) { $r->of(false); // turn off output formatting $r->cost = $input->post("cost_$r"); // and do the same with your other fields $r->save(); }

Here is the first release version of the Blog Profile! http://modules.proce...s/blog-profile/ It is now up on GitHub as well: https://github.com/r...ign/BlogProfile Below is a lot more talk about this blog profile and how it works, but if you just want to install the profile and test it, it's not necessary to read anything further unless you want to. I've simplified this a lot from where it's been. It does all the same stuff on the front-end, but the code behind the site is no longer a huge departure from the basic profile. I've rebuilt this profile 3 times trying to find the right balance between making it as flexible as possible and making it as easy to understand as possible. I think it's got a better balance now than before. It's now at a point where it does everything it always has, but the template code behind it should be a lot more accessible and easy to understand. There is no longer a separate module or API variable. Everything here just happens in /site/templates/ files. Consistent with making it simpler, I've also removed the drag-n-drop theme support. While it was cool to have, it always felt a little dirty introducing some kind of proprietary theme support that was so different from the way I'd build any other site. This thing is pretty darn simple to theme as it is (just edit a CSS file). Maybe we'll take it further in the future, but we don't have many PW site profiles out there right now (1 or 2?) and so I decided this profile needed to stay more accessible on the back-end. How the template files work In ProcessWire there are any number of ways you can use your template files. In this case, we are using our template files (in /site/templates/) to populate 3 variables ($content, $headline and $subnav) and then including an HTML file (main.inc) to output them in the right places. The $content variable represents the center (body) column, the $headline variable represents the text headline of the page, and the $subnav variable represents the navigation that appears in the left sidebar. Once one or more of these variables is populated, the template file includes the /site/templates/main.inc file. That main.inc file is just a big HTML file that outputs the $content, $headline and $subnav variables in the right places. We've made an attempt here to separate most of the logic used in the template files from the output. Most of the markup is generated from files in /site/templates/markup/. These files are included from the template files to output specific things like a blog post, comment, etc. Because a lot of output needs are similar among the various template files, we've created a file called /site/templates/blog.inc that has a few shared functions in it. If you look in any of the template files, you'll see that most of them include blog.inc as the first thing. This blog.inc file also initializes our $content, $headline and $subnav variables, mentioned earlier. Outline of /site/templates/ with this profile /site/templates/blog.inc Shared blog-specific functions included by most site templates. /site/templates/main.inc The main HTML markup file through which everything is output. /site/templates/markup/ Contains PHP files that generate markup for specific things like posts, comments, etc. This is separated from the site templates to make it simpler for you to modify the markup if you want to. This is primarily used by the blog.inc functions, but also included by a couple templates as well. /site/templates/skeleton/ This is the Skeleton CSS framework. It is identical to the one they distribute except we added a wider viewport to it. You probably wouldn't have much need to edit anything in here. /site/templates/styles/ Stylesheets used by the blog profile. The most useful one in here would probably be theme.css, which contains all the color definitions for the profile. /site/templates/scripts/ Javascript files used by the blog profile. Not much is happening in here at present.

Thanks for the info. That's easy to implement, so I went ahead and added it now and will read more tomorrow. Soma let me know if this does what it's supposed to? If you include a 'callback' get var, it just echos it back (after pageName sani) in the format you mentioned in the earlier message.