ryan

Looks great, thanks for this update!

Great--glad you found it. Thanks for updating it.

I think it's a great idea. This does sound like a really useful thing to have. It sounds like it could be complex, but in writing out the steps (if I have it right) it seems more approachable: Step 1: - You enter a feed URL - You select the parent page where it will create children - You select the template it will use - Click submit Step 2: - It loads the feed, looks at the first record, and saves all the field names in an array. - It displays all the PW field names from the template you selected. Next to each is a select box containing all the feed's field names. - You select one of the feed's fields for each field in your template. - Click submit. Step 3: - It loads the feed again and iterates through all the records. - It creates a new Page for each record, associating the fields you selected in Step 2. - It displays the pages it created. - Pat yourself on the back and drink a beer. What do you think, am I missing anything? Where it gets harder to create a universal feed import tool is with Page relations and file/image fields. But maybe those are for more specific tools, where something more is known about the data. If you decide you want to build a tool like this, just let me know what I can do to help.

Very nice site, thanks for posting this. Beautiful photography, and I like the use of that photo in the background. Also like the lightbox photo galleries you have integrated as well.

Austin, Apeisa has great suggestions. I also wanted to inquire about why you'd store 1 image per page rather than multiple images? Is it mainly because of the EXIF fields? If so, I wanted to mention that PHP has some built-in EXIF functions that may help: http://www.php.net/manual/en/ref.exif.php For tags, you could use the built in description field included with each image. PW also lets you upload a ZIP file full of images, and it'll extract them all for you and bundle them into the field -- this can be a real time saver. There's certainly nothing wrong with using 1 page per image, and it may be the right approach, but I just wanted to make sure I understood. There may be a way you can accomplish what you need without having to do the multi-page and custom module approach. As for preventing access to the full size image, you could also use an apache rule to block all images where PW has them stored, EXCEPT for those that have the resize dimensions in the filename. This would accomplish what you are asking for and it would be bulletproof, directly blocking access rather than having to hide the filename. To do this, place the following snippet somewhere in your /.htaccess file after the line that says "RewriteEngine On": # Block access to all images in /site/assets/files/[0-9]+/ that don't have # dimensions specified in the filename # RewriteCond %{REQUEST_URI} (^|/)site/assets/files/[0-9]*/.*\.(gif|png|jpg|jpeg)$ [NC] RewriteCond %{REQUEST_URI} !.*[1-9][0-9]*x[1-9][0-9]*\..* RewriteRule ^(.*)$ - [F] Note that this will block ALL non-resized images in your site. It won't block them from PW, which reads and resizes them from the file system, but it will block all http requests to them. So if there is a place in your site where you don't want this behavior, you would still have to create a resized version in your template code in order for the image to be http accessible. You could do this just by creating a version that's the same size, or slightly smaller than the original.

What I mean is that I don't understand the term 'knowledge base' enough to have a sense of what I'm going to get before I click there. It sounds like a term Microsoft would use. Just wondering if there might be some other terminology or organization to avoid the 'knowledge base' encyclopedic black hole. How about just 'Docs' or 'Using ProcessWire' or something like that? Actually I really enjoyed the points you brought up in your temporary text. I think you are hitting the mark on a lot of points, including your headline. I'm just not sure in what order the points should go. I think the primarily headline probably has to hit on a overall concept rather than a specific point. These are what I see as the overall concepts: Simple interface to powerful tools (kind of like Google's concept) Develop your sites more quickly and easily while having fun (kind of like jQuery's concept) Manage and develop your sites your way – ProcessWire works the way you do Obviously I'm not a copywriter, so these are just concepts not wording. This sounds perfect. I don't think there is a problem with the flow. I think it's just a matter or getting all the sentence/paragraph copy the same size and maybe compartmentalizing the sidebar a little more (if you think it needs it). So there may be a little bit of a horizontal flow in the bodycopy area to the sidebar that others are reacting to, but I'm not sure I see it (the flow made sense to me at first viewing). I suspect that reinforcing the sidebar with a slight background color, border or something will clear that up for anyone that doesn't get the flow at first, but that's up to you to decide if it's necessary. I like your font choices for the most part. The instances of Avenir + Mahalia aren't snapping together quite right in the headline and download button, but I can see that would be an easy fix. Either that, or you could just drop the Mahalia and continue about with the Avenir. I think the main headline and download button can be produced as images. But for everything else, we'll probably have to find a substitute that we can render in HTML (whether using @font-face or typekit, etc, or web-safe fonts). I'm not sure that we can get Avenir as a web font. But I'd like to find some way to carry through your headline styles throughout the rest of the site without having to resort to to any kind of image/flash replacement. While you have a lot of different headline styles on this page, I think it all works. It's only the 2-3 different sentence/paragraph sizes that I wasn't sure about. I also understand that these are details that really aren't significant at this stage, and you are trying to provide the big picture which I understand and think is great. Lets keep the momentum going when you are available and let me know what I can do to help. Btw, were you thinking this would be fluid width? It looks like you've designed for that very nicely, but wanted to confirm.

Currently we are using the bugtracking system provided by GitHub. I've been happy with it so far. But we're always open to suggestions if anyone thinks another system would be better. I like the idea of an API cheat sheet reference like you mentioned. I've got a 1-page VIM cheat sheet tacked on my wall. Might need something like this for ProcessWire. As for community-supported knowledge base wiki, I like the idea of this. I think we'll pursue it as soon as there is demand and a perceived need for it. I think this might be especially useful in maintaining documentation for 3rd party modules.

Antti, thanks for recapping the roadmap. It's interesting to look back and see what we've covered. I've not been referring back to that post very much so am glad to see it's still very relevant. I have a few more details on some of the items: The FormTemplateProcessor.module probably applies here as some progress, but it's only a start and proof-of-concept. I'm thinking we'll want the form builder to be the drive behind version 2.3 (after multi language). Though I still think this functionality will be module driven rather than core driven. I've been surprised how little this comes up. Before going open source, I had figured this capability was more important than something like multilanguage support. Now I know better. PW1 did have versioning built in and version functions do add some complexity to the system. But I'm thinking less than 30% will even use it. As a result, I'm going to target this as something that will be built as a module rather than part of the core. This is done, but I still want to find a way for people to preview updates to a page before publishing them. Currently there is no way to do that for an already published page (short of unpublishing it). This will also be built as a module rather than as part of the core. Actually this is already started. It's the new ProcessPageSearch in 2.1. The plan is that it will output it's results in JSON when $config->ajax is true. I think that we probably won't be pulling much more out of the core to place in modules, unless a new need comes up where it would seem beneficial to do so. Moving the Page::viewable, Page::editable, etc. functions out of the Page class and into the PagePermissions module was one of the last instances where I moved stuff out of the core and into a module. But I'm not sure that there was much benefit in doing that. So I would change this roadmap item to be: simplifying some of the core classes to make them delegate some functions (where appropriate) to other core classes or modules. For instance, the Pages class will probably be simplified to delegate most of it's code to other more specific classes, like the Pages::save() function will probably be moved into a PagesSave class. However, this is just system architecture -- none of this will change anything about the API or how you use ProcessWire. It will just make it cleaner and more maintainable long term and provide opportunities for more hooks. Actually I built one of these that uses jQuery UI's autocomplete a few months ago. It's mostly functional, I just need to finish it. I'll be happy to send it along to anyone that wants to tinker with it.

I've been hunting for it too and can't find it. Now I'm wondering if this is something we were talking about via email rather than in the forum. I'll keep an eye out for it.

Antti, this looks great, nice work! Really well put together code here too. I am looking forward to using this module in future projects. Great screencast too. I think we need an AutoCron module that provides 1 min, 30min, 1 hour, 6 hour, 12 hour, daily, weekly and monthly hooks that any other module can hook into and expect that whatever function it hooks will get executed according to the time they requested. AutoCron would run on every page request, but only execute it's timed hooks when a set amount of time has passed. This will actually be an easy module to build... I think I will get something started here, because we need a core module to provide this capability. I'm thinking this is something like Drupal's poor man's cron, though I've yet looked at that in Drupal. Actually ProcessWire modules should automatically install when another module requests them. So when you do this: $module = $this->modules->get("MarkupCache"); It should the module if it isn't already. Since MarkupCache is a core module, you can count on it being there so no additional error checking should be necessary. But for any required 3rd party modules, you should check that the returned $module is not null whenever you are using it. If it's null, then you'd want to abort or throw an exception alerting them they need to install whatever module is missing. This is better than checking in your install() function because it covers the possibility that they might uninstall a required 3rd party module sometime later. In 2.1 or 2.2, we should probably update to the core to track module dependencies so that the above is handled internally by the system rather than the module developers. I don't think there is any overhead in adding a custom method to all pages. Behind the scenes, it's only added once to the actual Page class rather than all $page instances separately. So I think your method here is good. I also put together a Twitter module for use in processwire.com awhile back (MarkupTwitterFeed.module). The output it produces can be seen in processwire.com in the sidebar on most pages (minus the forum). It's a completely different thing from yours and doesn't do nearly as much, but figured I'd post in case you were interested. It does maintain it's own cache file... I didn't use MarkupCache to do it here because this module was written before MarkupCache existed. MarkupTwitterFeed.module

Page Link Abstractor module for ProcessWire 2 Plugin module that lets you move pages in your site without worry of ever breaking static links on other pages. Download at: https://github.com/ryancramerdesign/PW2-PageLinkAbstractor What it does Converts links in textarea/rich-text fields to an abstract format for storage, and converts them back at runtime. This means that if you move a page and another page is linking to it, the link won't be broken. It also means you can move your site from subdirectory to root (or the opposite) and not break links you may have created in your textarea fields. This applies to any kind of links: pages, files, images, etc. This module will also notify you when you edit a page that has a link to a page that doesn't exist or is in the trash. This module has been tested with ProcessWire 2.1 but should also work with 2.0. Since this module has not yet had a lot of testing, it should be considered "beta" and use is at your own risk. Please let me know of any issues or bugs you run into. How to install 1. Download the PageLinkAbstractor.module file from https://github.com/ryancramerdesign/PW2-PageLinkAbstractor and place it in: /site/modules/ 2. In the admin control panel, go to Modules. At the bottom of the screen, click the "Check for New Modules" button. 3. Now scroll to the PageLinkAbstractor module and click "Install". 4. Edit any of your textarea fields in Setup > Fields. You'll see a new configuration option to enable this module for that field. How it works This is a technical explanation for how this module works for those that are interested. Reading this is not required in order to use this module, but it may help you to use it more effectively. When you save a page that has a textarea field with this module enabled, it will look for URLs in HTML attributes by looking for an equals sign followed by a URL. It replaces instances of your site's root URL with a special tag: {~root_url} Next it checks to see if any of the URLs it found can be loaded as pages in your site. If so, it replaces those URLs with this special tag: {~page_123_url} where "123" is the Page's ID. When the page is loaded, ProcessWire does the opposite and converts those special tags back to their URLs. Because the URLs were abstracted to tags that are generated at runtime, when a page (or a site) is moved, no links are broken. Note that this module only converts URLs to tags when you save a page, so it only affects pages saved after the module is installed. Where to use it This would be most useful on your main 'body' field that uses a rich text editor (like TinyMCE). Where not to use it There is some overhead in using this module that will be insignificant if you use it carefully. Here are a few instances to avoid using it: Avoid use on fields that have the 'autojoin' option on, unless your site doesn't load lots of pages in a given request. Don't use on textarea fields that can contain anonymous (guest) user input. Avoid use on fields that aren't likely to contain links to local site pages in HTML markup. No need to have this module parsing things unnecessarily. Avoid use on fields where you think you might disable it later. Once disabled, the abstract tags representing the URLs will still be in place. If the module is disabled, those tags will no longer be converted to URLs are runtime. You would have to correct them manually by editing the page. Side benefit The tags that this module abstracts to are intentionally fulltext indexable, so you can perform searches for these tags. This means that you can find all pages linking to another by searching for it (minus the brackets and "~"). For example: $links = $pages->find("body~=page_123_url"); That would return all [viewable and visible] pages linking to page ID 123. Please note In order to convert URLs for pages, this module needs to load those pages in order to obtain their URL. If you are linking to a hundred pages in your 'body' field, you should expect that it may slow down the page 'load' and page 'save' time for pages containing lots of links. This module doesn't yet abstract local URLs that have a schema/protocol and domain in it. It just works with path-type links like /path/to/page/ and not http://domain.com/path/to/page/. This module hasn't yet been tested with migrating a site from subdirectory to root, but I will be testing this soon.

Slkwrm, thanks for these links. I took a brief look and these look very helpful. You'll be glad to know that multilanguage support is scheduled as the main drive behind ProcessWire 2.2, being developed this summer. I'm not an expert with i18n and l10n (yet), so I'm doing a lot of reading and links like those you posted are very helpful and I will be reviewing them in more detail. Likewise, having people around here that are well versed in this stuff is really helpful too, so please stick around. We will need all the help we can get with regard to testing, translating, etc.

We will plan to put together a blank(er) install profile with 2.1. Technically, there isn't really such thing as a completely blank installation because so much of ProcessWire itself is built in it's own framework. It's admin, user, role and permission system is built on a structure of pages, as are it's required homepage and 404 page (these are non-removable system pages). There are also several fields and templates built-in that it requires (called system fields and templates). Though the main ones you'll see are the 'title' field and the 'admin' template – PW hides the others unless you use the filters in the Setup > Fields/Templates part of the admin. A blank install profile would be like the current install profile, but with just 1 non-system template (like page.php), homepage, 404 page and admin page structure, and no body, sidebar or images fields. We'd make the default included template just be a blank HTML5 skeleton page, maybe linking to a blank stylesheet. I guess that the current install profile is kind of built around my own needs because nearly every site I build has at least the included fields and templates, so for me it's a much quicker starting point than a blank profile. But a blank profile has been requested a few times, so clearly there's a need for it and we'll make it happen.

You'd want to setup your title fields in the same way as your alternate language body fields. But are you talking about the display of the title field in the admin Page List? We don't currently have a way to select a field dynamically according to language in the admin Page List (though we will in 2.2). As a result, separate trees are currently a better solution for multi language if you need the language to be reflected in the admin Page List.

Thanks for spreading the word! Glad to hear there is some interest.

Hi Will, Thanks for your post and offer to help! I saw on your site that you've been at this for 15 years–sounds like we started developing on the web about the same time (~1994). We are glad to have your experience and expertise here. I've been working on a partial list of the things that I think we will need help with (whether current or future), and I posted it here: http://processwire.com/talk/index.php/topic,268.msg1610.html#msg1610 Those are ideas and open to changes. Anyone is welcome to add to that list too. Here are some other ideas aimed at anyone reading: My opinion is that one of the best ways everyone can contribute to ProcessWire right now is to write. Write about it, what you are doing with it, and how you are doing it. Maybe a tutorial to tell other people how to do something (like how are you merging PW with other technologies that you use, for example). Post your articles on your site, this site, or another (like cmsreport.com). If you like to write code better than paragraphs, write modules, admin themes or site profiles to share. If you like to get into the technical details of PW, fork the latest dev version on GitHub, optimize and improve it. If you like to write URLs, then link to processwire.com -- we need to improve our pagerank so that others can better find us through search -- our pagerank is currently 0 out of 10 according to Google (though we've not been online for long). Thanks, Ryan

Fantastic site! Thanks for describing the different parts and how you built it. Also to the best of my knowledge, this is also the first P21 site. This is my new favorite ProcessWire site even though I can't read it. Great work!

Very cool Adam! I really like where you are going with this. This is a huge improvement, and I'm really honored that you did this. I particularly like your information structure and the way the page grabs you. There is a lot of good thinking and organization here, and this is a very active and compelling homepage. Thank you for your efforts here! I'll go through each part with some questions and comments. Masthead: Nice looking masthead and navigation. Wondering if it also needs a download link (for other pages in the site)? I like the underline under 'why processwire' but not so sure about the one in 'home'. What is 'knowledge base'? Do you have any thoughts on placement of a search engine box whether here or somewhere else? Feature Area: This really draws me in. We probably need to come up with a different headline (or use this one in a group of rotating headlines), but I like the focal point you've created with it. I like the pink background, but know it's a risky color with small type on top of it... what do others think? Love the download button right there. The screenshots are great, but not yet sure about the vignetting on them. I wonder about possibilities for video here... though screenshots may lend to a better overall page look + feel, what do you think? I like that you are integrating the Mahalia font into other parts of the design. My opinion is the Mahalia may benefit from being smaller in the headline, and slightly bigger in the download button. Content Area: I enjoyed your copy writing. This content area flows very nicely. I think this is right on. The Item of the Day is a great addition, thought might like it to be "Featured Plugin Module" or something like that. Might like it's headline on top of it (rather than inside) to optimize the space within. Footer: Every section of the page draws you in and the footer is no exception. But that footer might like a little more vertical room. The PW logo and official tagline over on the right looks a bit lonely–might prefer it anchored with your 3rd column Other: Very minor, but I think there may be possibly too many font sizes in the page? I like the grid you've carried through top to bottom, and wondering what you think about bringing the top nav into that grid (for it's left edge to line up with column 2)? There's so much to like about what you've put together here. It does feel pretty consistent with the brand that's already going and I wonder about the possibility of putting something like this as the new homepage sooner rather than later (before redoing the rest of the site). I'm extremely picky and you've really impressed me with your work. Our creative director (Karen) is also applauding right now.

The $config API documentation has been posted here: http://processwire.com/api/variables/config/

I duplicated the tree you setup, and I was able to reproduce it. Thank you for your testing here. I found that the first child of a parent wasn't triggering population of the pages_parents table, which is what the Page::find() operation uses. That explains why the pages in category1 were being found but not the page in category2. Hopefully this is now fixed in the latest commit. Thanks, Ryan

I like your idea about "if viewing rights are changed", that could be the right solution for this.

Adam is correct (thanks Adam!). To follow up, it is zero based. And if you'd prefer to specify "start" and "end" rather than "start" and "limit", you could do this: $page->children("sort=-created, start=4, end=5"); However, I usually find it simpler to specify a limit. Also, since you are only asking for 1 item, there really isn't any need to use the foreach() and children(). Instead, you could just use this: $child = $page->child("sort=-created, start=4"); That will always return just 1 item, so there's also no need to specify a limit or an end.

Thanks, this is a really helpful example and well explained. I'm going to attempt to duplicate the same scenario here, and have a feeling this will lead to a fix.

Thanks for your feedback and offer to assist -- lets plan to keep in touch as we get closer to that time. The sproutcore guides look to be an interesting format, good link.

Sounds like a good idea to me. I'm just not yet sure how best to implement. For instance, if I did this on the site I'm working on now, I've got 5k+ pages under /villas/ and all of them would have the key icon because their access is different from the parent. Maybe that's okay... going to try some things.