ryan

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.

To redirect requests for just "/site/", you could do something like this in your main PW .htaccess file (after the 'RewriteEngine On' line): RewriteRule ^site/?$ / [R=301,NC,L] That would redirect a request for /site or /site/ to the root. If you have to account for additional URLs off of /site/, then you'd want to do something like this: RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^site/(.*)$ /$1 [R=301,L,QSA] That would redirect requests for /site/[any file or path that doesn't exist on the disk] to the same path off of root rather than /site/.

Great module! I'm testing here and it seems like a nice usability improvement. I'm going to use it on my site for a little while to test, but already thinking I agree this might be good to have standard… perhaps as something that can be enabled/disabled from the ProcessPageList module settings. Maybe a good core addition for the upcoming 2.3 version. As for module name, I think you've got a good name except for the 'Process' part, which we usually reserve for modules that extend the Process class. I would instead suggest maybe PageListPin or something like that?

It's a bug, but was fixed. You should be able to fix it just by pulling in a new /wire/ dir. I didn't update the version number for this one since it was pretty minor.

You should be able to drag them to the order you want. They are in the admin page tree as children of /processwire/setup/languages/. They may be set for alpha sorting, in which case you'll want to change to manual sorting. I think you must be running an older version of 2.2 because this issue was fixed 6 months ago. Update the version of your source and it should resolve the issue.

I think you are probably best off using 2.2. There aren't major compatibility differences between 2.1/2.2 (like there were between 2.0/2.1) so no real reason to stick with 2.1.

I have gone ahead and added this capability to the dev branch. Now pages with repeaters can access images within the repeaters, and repeater pages can access images from their containing pages.