ryan

Form Builder is one way to do it. But it's actually very simple to create pages anywhere in ProcessWire from the API. Here's a simple example: $page = new Page(); $page->parent = '/about/'; // or whatever parent you want $page->template = 'basic-page'; // or whatever template you want $page->title = "Test Page"; $page->body = "<p>This is a test, only a test.</p>"; $page->save();

Also, don't forget to enable page numbers for your template (Setup > Templates > your-template > URLs > Page Numbers).

Since these are API functions, you don't "see" the images, so center cropping is really the only safe way to crop without visual context. If you want to prevent any cropping from the API side, then you would just use the width(x) or height(y) functions rather than size(x,y). I also suggest looking at apeisa's Thumbnails module, which provides interactive cropping capabilities.

You'll also want to give your Editor role page editing permissions. You'll see these when you create the role. After you've done that, you still need to apply those page editing permissions somewhere. Go and edit the 'home' template (Setup > Templates > home). Click the 'Access' tab, and check the boxes for your new 'editor' role.

You can also edit your /site/config.php and locate the $config->debug line and change it to: $config->debug = true; That should put any generated error messages in front of you. Let us know what you find?

I'm really happy with photoswipe (originally recommended to me by Soma). It really duplicates the native mobile gallery experience beautifully. At the same time, it's quite a nice way to browse photos on non-mobile too (you can even drag the photos with your mouse). Example

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.