ryan

There isn't an easy way to do that, but you can easily setup your alias from your .htaccess file. For instance, say that you wanted this URL: /site/assets/files/123/somefile.jpg to be accessible at this URL: /123/somefile.jpg You could do that with this rewrite rule, placed in your .htaccess file right after the "RewriteEngine On" line: RewriteRule ^([0-9]+/.*)$ /site/assets/files/$1 [L,QSA]

The TextformatterVideoEmbed module has been updated to support responsive embed codes. To enable, grab the latest version (v1.0.4) go to the module configuration screen and check the responsive box. Now when your videos are embedded, they will be output in a width-flexible format that adjusts to the container.

That sounds fine to me. But just send the usage for me to see it in context once you've got it.

Page::rootParent has been made hookable (now in the dev branch)

This is exactly correct. Lets say you've got this page /user-profile/ in your site. You also have a template called user-profile, and it has URL segments enabled. In the code, all you need to authenticate is to compare $user->name to $input->urlSegment1. Meaning if user 'onjegolders' accessed the URL: /user-profile/onjegolders then you would allow them to make changes to their profile. if(!$user->isGuest() && $user->name === $input->urlSegment1) { // user is authenticated and may change their password if($input->post->submit_pass) { if($input->post->pass !== $input->post->pass_confirm) { echo "<h2>Passwords do not match!</h2>"; } else if(strlen($input->post->pass) < 6) { // if you want to enforce a minimum password length (recommended) echo "<h2>Your password is too short. Must be 6 characters or more.</h2>"; } else { $user->of(false); $user->pass = $input->post->pass; $user->save(); $user->of(true); echo "<h2>Your password has been changed</h2>"; } } echo "<form action='{$page->url}{$user->name}' method='post'>"; echo "<p><label for='pass'>Change your password</label>"; echo "<input type='password' name='pass' /> "; echo "Confirm: <input type='password' name='pass_confirm' /></p> "; echo "<input type='submit' name='submit_pass' />"; echo "</form>"; } The above was just written in the browser so may need tweaks.

Technically the pageName sanitizer isn't actually necessary here (as PW wouldn't even get the request if the pagename wasn't in the right format), but it is a best practice to sanitize anything you are planning on putting in a selector. So I would do it the same way as apeisa and sanitize with pageName, even if it's not technically required.

Wow this needs to be made into an admin theme. I really like the look of this!

I think this sounds very useful, nice job with this. The solution to not having your draft pages show up in menu listings/searches is just to make use of the "hidden" status, already built into every page: $page->addStatus(Page::statusHidden); $page->save(); Once a Page has hidden status, it won't show up in any multi-page retrieval functions unless you specify "include=hidden" or "include=all" in the selector. Tested out here and seems to work very well! Thanks for your work with this module. Wouldn't it be great if it would replace the original page once you published/unhid it? (and also deleted the draft). That would bring some great workflow potential... something I can see using all the time actually. But it would have to retain the id and name of the original page, so it would be more like moving the data to the existing page than actually replacing the existing page. If you are interested in doing this, let me know what I can do to help. Some other suggestions I have: - Use an integer for your version number. To reproduce the version number you have, you'd just use 10 rather than the string "0.1". - I think it might be nice to make the PageList label just "draft" rather than "create draft", so it ties in better with the others. Also would be nice to make any of your text translatable like "draft" and "(DRAFT)". You can do this just by doing $this->_('draft'); rather than 'draft'. - If a page is already a draft, it might be nice if it doesn't have the "create draft" option.

The "../../../../" looks odd to me, as you shouldn't see that kind of relative path in any ProcessWire $config->paths variables. What is the directory setup? Are there symlinks involved? Another odd thing here is that this error comes from /wire/core/TemplateFile.php, meaning something is trying to render the user.php template (which of course, does not exist in any PW install unless you add it yourself). My best guess would be that there is another module involved here that is trying to render a page, as there's nothing in the core that would be trying to render a page when you save a user (at least, nothing I can think of).

This is great, thanks for posting this.

I should mention that this blog profile is just one approach to ProcessWire templates. This one was intentionally made to explore an entirely different path than what is used in the default profile. The approach is probably different from what you'd see in most ProcessWire sites, but I think it's a good approach for long term scalability, especially when the front-end and back-end development are handled by different people. Though there are also other equally good approaches too. In the blog profile, a common include file (/site/templates/blog.inc) was created to house shared functionality that is used by multiple templates. This file just contains standard PHP functions that the individual templates call upon. For example, the ability to render blog posts (whether full or summarized) is something utilized by several templates in the site. Unlike the basic profile, the blog profile delegates most of the markup/HTML generation to files in /site/templates/markup/. Most of these markup generation files are called upon by functions in that blog.inc file. This is very much like an MVC approach. While I think the approach may not have as much practical value on a smaller site, it does make the output very easy to edit. Most of the decision making happens in in the individual template files. While all the markup/HTML comes from the files in /site/templates/markup/. When you want to make markup changes to common output, the files in /site/templates/markup/ have this profile covered. In my own sites, I usually take a similar approach except without the /markup/ files. I usually bundle the markup generation right into the shared include file (like blog.inc). That makes it simpler for me to maintain, though the blog profile approach would be better when there is a team of people (rather than one developer).

I agree, cookies would be the way to set this up. You'd just set a cookie with the user's name and pre-populate the field with the name from the cookie (after sanitizing it with $sanitizer->pageName). You could do this with PHP or Javascript. But I'd probably use PHP just because the logic of figuring out when to store the value (after login) would be simpler from the PHP side.

This is really a great module and I'm enjoying using it. Thanks for your efforts here. I think it makes sense to have it in the 2.3 core. But for 2.2, would you mind adding this one to modules.processwire.com? http://modules.processwire.com/add/

The infinite scrolls drive me nuts. But I agree it would be fun to see how one has implemented this.

Guest access can't be turned off from the homepage because that's one checkbox that has potential to take down an entire site. It's built-in to reduce support burden. And it's in response to me having clients do this on two occasions and calling me in the middle of the night because their entire site went down. How they managed to do it, I don't know. But it convinced me that I shouldn't have a checkbox that can take down an entire site. I think that Teppo's solution is a good way to go. Another would be to put this in an autoload module (though I haven't tested): public function init() { $this->addHookAfter('Page::viewable', $this, 'hookPageViewable'); } public function hookPageViewable(HookEvent $event) { if($event->return === true) { $page = $event->object; if($page->template == 'admin') return; if(wire('user')->isGuest()) $event->return = false; } }

I agree with SiNNuT on this one, though the likes of Symfony aren't a social platform out of the box either. I think that unless you use a pre-packaged setup like those mentioned (buddypress, etc.) you will be custom coding many of the features. And ProcessWire is a good place to do it. But you'd probably want to start from the vantage of a smaller project with ProcessWire to evaluate and determine if it's the right framework for your needs.

Thanks, I have added this as an issue in the queue. https://github.com/ryancramerdesign/ProcessWire/issues/132

It shouldn't be. PW only sets this on login, and it should be retained for the session. There isn't any code preventing modification of it.l Double check that the value you are carrying in $user isn't the same one that's already in _user_id?

That code looks good to me, except for one thing: just change if($who) to if($who->id).

Since you'll be maintaining separate thumbnails from the large images, then I would just consider any images you upload to your PW install to be thumbnails. You can set the max width/height in the image field settings, so you'd just choose dimensions that are consistent with your thumbnails.

Not sure. It seems to work here -- This was one I actually tested before posting. The only thing I can think of is to make sure that you are putting those directives immediately after the "RewriteEngine On" and not after some of ProcessWire's directives. Though sounds like you may have already found another solution for this? Though admittedly I'm confused as to why that would work, because "site" is a directory that should exist, and thus PW shouldn't be getting control for a request like "/site/".

Michael, let us know how your event goes. Thanks for sharing ProcessWire there.

So it looks like PHP 5.2 is the common denominator. I must be doing some PHP 5.3 specific code without realizing it. I'll experiment more here and hopefully track down the relevant code.

Thanks, I think I understand what you mean and was able to implement a fix. Since it has potential to affect other things, I've put it in the dev branch for testing. If you want to try it out, replace your /wire/core/PagesType.php file with the one from the dev branch: https://github.com/ryancramerdesign/ProcessWire/commit/f2b63ec23cf8bb817eacf2c81434c354fc651dcd

Thanks for posting those, the screenshots answered it. Looks like I had an htmlentities() call without the 'UTF-8' in it for that header cite line. This has been fixed and committed to the source.