ryan

Shouldn't be a problem if its generating a thumbnail. The update is really meant to be as transparent as possible. Here's what's happening with the protected files: Originally you have a URL like this, which is a direct link to the file: /site/assets/files/123/file.jpg When it becomes protected, ProcessWire renames the "123" part to ".123", which according to PW's htaccess file makes the directory blocked from http. (I will probably change this to some other strategy, because directories with periods at the front might be skipped by FTP clients and such). The new link for the file becomes: /path/to/page/-/file.jpg, a URL that will be handled by ProcessWire rather than pointing directly to the file. (the "/-/" part is configurable... it could be "/files/" for instance, if you preferred it). When PW sees that unique URL segment "-" or "files" (or whatever), it first checks that the user has access to the page (/path/to/page). If they have access to it, then it checks if the requested file exists in /site/assets/files/.123/file.jpg. If it exists, it sends it to a passthrough function which outputs the file. From the perspective of the API, you should not have to make any adjustments in how you work with it. Your code doesn't even need to know that the file is protected. It should all just work without side effects. However, if you are generating your own URL to the file (rather than using the one PW provides) then that won't work, because not only does the "123" directory no longer exist, but the new ".123" directory is not even http accessible.

Great module! Post please post to modules.processwire.com at your convenience.

Thanks again for this feedback, really makes me smile! One issue I'm running into with TypeKit on the site is that I'm getting an FOUC (flash of unstyled content) when viewing the site with Firefox (latest version). Not seeing it in any other browsers. I'm assuming its got something to do with TypeKit since the the unstyled content is specific to the typogrpahy. Is anyone else seeing this, or does anyone know how to correct it?

Thanks for tracking this one down Teppo -- I will update the source to correct this per your fix.

Here is the same thing rewritten to be more verbose. $user = $this->user; // current user $page = $event->object; // page where editable(); function was called $user->editable_pages->has($page)) { // user's editable_pages field has $page in it // so we set the editable(); function's return value to true, // which means: "yes give them edit access" $event->return = true; } I should, but sometimes forget since I don't often use the multi-language features myself. I will update the module.

Thanks! Looks like I had an extra slash in there, now fixed. For you guys that asked for admin screenshots, I looked around to see if there was anything interesting worth making a screenshot of. Maybe the homepage editor? Here it is:

Thanks for the kind feedback guys, I appreciate it. I'd be glad to make a couple screenshots, but it would look not much different than the basic profile. It is all standard ProcessWire on the admin side. I don't know an answer to this, but I do know that it's possible. Just last week I was filling in a long form online and it sent me a PDF of the completed form. Almonk made a PDF generation module awhile back that may provide a good starting point. I wasn't sure how to handle mobile with the calendar because the calendar doesn't have a top-to-bottom agenda view that would work well in mobile. So I went ahead and modified it so switch to just the daily view when the screen size goes into mobile width. This seems to work fine at mobile. I'd still like to find a way to show a whole month in a mobile view, but think I'd need the FullCalendar plugin to support it before I could implement it. Not sure I understand? Or at least, I don't see them not working. What browser/version?

Great idea! Thanks for making this, it's very useful. In your API example, it says "$u->reset = 1;", is "reset" the name of the field, or is that a static name to always use? Also wanted to suggest removing the "permanent=true" from your getModuleInfo() because that will prevent people from being able to uninstall it.

Any idea why it doesn't work? As long as it requests the image URL from the file/image field, rather than self-generating it, it should continue to work. Let me know if you'd like me to help troubleshoot this.

Just checked -- it looks like its not in the cheatsheet. Soma, if you are reading this: can you add it, or tell me how to add it?

I wouldn't call a page named "Tools" a feature. PW1 may have had some features that aren't yet in PW2, but PW2 is overall a superior system. PW1 existed for a longer period of time so naturally grew in feature set over time. The same will be the case with PW2, and it won't be long till we blow way past the feature set in PW1.

I'm not familiar with a jQuery plugin like that, but would also be interested in learning more about it if anyone does know of something like this.

Thanks for testing it Soma. So far I can't seem to duplicate the error. Can you think of anything else necessary to duplicate? Also, what version of PHP?

Glad you figured it out! I didn't know what to suggest next.

Ah sorry I was looking in the wrong place. It looks like I missed a closing quote on that meta tag: Change this: <?php if($page->summary) echo "<meta name='description' content='" . strip_tags($page->summary) . " />"; ?> To this: <?php if($page->summary) echo "<meta name='description' content='" . strip_tags($page->summary) . "' />"; ?> Does that fix it?

The opening <p> should already be there since its a TinyMCE field. But if there were any posts still in place that hadn't yet been saved with the new TinyMCE field, then this could account for it. I think the fix would be to go and save all the posts that don't yet have TinyMCE markup. Or account for either possibility in the code: if(strpos($page->summary, '<p>') === 0) echo substr(trim($page->summary), 0, -4); else echo "<p>" . $page->summary; echo "… <a class='more' href='$page->url'>" . __('View More') . "</a></p>";

Just launched this site a few minutes ago. It's not totally done, as I've still got some detail work to do, but figured it was at a good point to share: http://www.houghtonacademy.org I did the design and development on this one. Like the blog profile, this one uses the Skeleton responsive CSS framework. Though I went a lot further with the media queries on the mobile side than I did for the blog profile. So you should see a nicely optimized layouts for tablets, mobile portrait and mobile landscape. So far only tested on iPhone though. Many of the graphics (though not all) are also optimized for Retina displays. When you get to the homepage, you should get a different photo and tagline on every page load. Highlights (in terms of ProcessWire development): Faculty Directory: http://houghtonacade.../about/faculty/ The data for the faculty directory is updated once daily and it pulls from a service called Veracross, that manages all their school systems. They are all represented as pages in ProcessWire, so the client can add unique biographies and such that aren't present in the service it pulls from. Form Builder is used throughout the faculty directory to power the individual employee contact forms. Events Calendar: http://houghtonacade.../news/calendar/ The events calendar uses jQuery plugin FullCalendar and it pulls from a ProcessWire-powered JSON feed. ProcessWire gets the data from a Veracross feed a few times a day, caches it, and creates a new feed specific to use with FullCalendar. The events data is also used on other pages in the site, such as the homepage. Photo galleries: http://houghtonacade...f/photogallery/ There are several photo galleries throughout the site, and they use the Photoswipe jQuery plugin, which is really great when using mobile as it duplicates the behavior of using the built-in iPhone photo gallery. Thanks to Soma for recommending this back in another thread. Video pages: http://houghtonacade...out/headmaster/ These are powered using the TextformatterVideoEmbed module and are responsive (per the latest update to this module).

This should work, but one [minor] thing to note is that I've setup that summary field to double as the <meta description>. You could go ahead and just create a new field and call it 'meta_description' (or something like that), or you could continue to use the existing 'summary' field, but you'd want to strip the markup out of it for placement in the meta tag: In /site/templates/main.inc, change this: <?php if($page->summary) echo "<meta name='description' content='{$page->summary}' />"; ?> To this: <?php if($page->summary) echo "<meta name='description' content='" . strip_tags($page->summary) . " />"; ?> (basically you just add the strip_tags). Another minor thing is that the <div class="post-body"> now has doubled <p> tags around that summary. That's because the it was previously assuming that the summary wasn't marked up. Since it is now marked up (TinyMCE), you'll want to do this: In /site/templates/markup/post.php, change this: echo "<p>" . $page->summary . "… <a class='more' href='{$page->url}'>" . __('View More') . "</a></p>"; To this: echo $page->summary . "… <a class='more' href='{$page->url}'>" . __('View More') . "</a>"; (basically just remove the surrounding <p> tag) If you want to have that "View More" link contained within the last paragraph, rather than on a separate line, you could do this (I think… writing in the browser here): echo substr($page->summary, 0, -4) . "… <a class='more' href='{$page->url}'>" . __('View More') . "</a></p>";

That's correct, this is how it's setup here. The assumption is that "author" would be a limited access editor that you might only give access to post new blog entries, but feasibly you might give them access to add categories and tags too. So the role is setup and ready for you decide what you want "author" to be able to edit. I would suggest giving author access to edit posts, categories and tags, but not home or widgets.

I was actually thinking of adding a "Tools" menu to ProcessWire admin (in addition to Pages, Setup, Modules, Access). The reason for it is that we've now got a lot of tools that don't necessarily fit the definition of "Setup", so thought it might be handy to come bundled with another place like that. PW1 had such a Tools menu like this.

Don't give me too much credit guys. I've got all of 15 minutes invested in this particular module, and most of that was writing the instructions. But the subject came up on another thread and just wanted to have a proof-of-concept of how simple it is to plugin your own hooks to customize user access in any way you want.

Thanks Mike! Great addition -- I will update the profile to make this change. One thing I wanted to mention about this blog profile. I know that you are evaluating ProcessWire among other CMSs, and wanted to highlight that the Blog profile might not necessarily be the best single place to evaluate ProcessWire from. It's just one application/template approach among many that people use. I think that the Basic profile included with ProcessWire actually does a better job of revealing the inherent simplicity, and path-of-least-resistance, of the template system. Whereas the Blog profile gets into using ProcessWire in a more MVC front-end framework approach. So it was intended not just as a blog profile for people to use, but also as a next-step (from the basic profile) demonstration of a more advanced approach. This is a great approach to use, but I usually get people started with the basic profile before exploring this, and other approaches. I'm guessing you probably know all of this already. But even if this is old news to you, I figured I should also mention this for others that may be reading about the blog profile.

PW 2.3 protects file-based assets to unpublished or non-public pages, so this won't be a concern much longer. Matching up names is just one way to do it. I just put together a quick module that provides another way you could do it even more easily:

Assign edit access to individual users on a per-page basis The user must already have page-edit permission on one of their roles in order to get edit access to assigned pages. Otherwise, they will only gain view access. This module is fully functional as-is, but intended as a proof-of-concept for those wanting to go further with adding custom edit and/or view access. The main functionality in this module consists of only a few lines of code, so it should be a simple edit for anyone wanting to take it further. If you make some useful additions to it, please post them. How to use Create a new role called "editor" (or whatever you want to call it) and give the role "page-edit" permission. If you already have a role in place that you want to use, that is fine too. Under "Access > Users" locate the user you want to assign edit access to. Edit this user. For this user's "Roles" field: choose the new role you added, "editor" (or whatever you called it). For this user's "Editable Pages" field: select one or more pages you want them to be able to edit. Save the user and you are done. To test, login as the user you edited to confirm it works how you expect. http://modules.processwire.com/modules/page-edit-per-user/ https://github.com/ryancramerdesign/PageEditPerUser

Antti coded the HTML5 upload capability and may be able to speak to it better than me, but I don't think we have control over that particular order?