ryan

Very impressive module Horst! I look forward to using it. Please post to the modules directory too if possible. Thanks for your great work here.

I think it's best though just to keep it simple and use the template file home.php as your homepage template, and keep that on your root page.

They shouldn't be compressed. Regarding the 1-line issue, we can correct this on PHP 5.4 and newer as json_encode() now has a JSON_PRETTY_PRINT option, which makes it output the JSON in a human readable way (and I'm assuming a much easier-to-version way). I'm going to add a check for PHP 5.4 so that we can start taking advantage of this now.

The $cacheFile->remove() should remove all files in the cache directory for that page. Probably what would be better is just to call $cacheFile->remove() regardless of whether the individual cache file exists -- so your suggestion is a good one (but will use remove rather than removeAll). Secondary ID is a combination of $options (prependFile, appendFile, filename), page number, language and perhaps some other things I'm not thinking of. I can look at opening it up to more options. MarkupCache is also another option, that lets you have full control over the cache ID. I'll look into this option. Though the MD5 includes things outside the $options array as well, but perhaps the entire $options should be part of it.

I actually have no idea what you guys are talking about–tell me what to change? I understand code better than concept when it comes to CSS, so might need you to be literal as to what you suggest?

When you uncache a page, it also triggers an uncache() method on all the page's fields. Fieldtypes can decide how to handle that. If those fields are objects, then they may choose to uncache themselves as well. Depending on the fieldtype, this could mean that they essentially reload from DB the next time you access them. Text fields on the other hand are just text, not references to other object instances–so there aren't any external references to uncache. When you clone a page, it creates a second copy of everything (including the fields it references). By uncaching the clone instead of the original, you are effectively uncaching it from the ID cache of $pages only. A shallow uncache rather than a deep one. All the fields on your clone are still being uncached, but your original $page is still in tact and an uncache hasn't uncached your changes. Basically, I think what you are doing makes sense and is probably the right way to go here. Though it might make sense for me to add a $shalllow option to the $pages->uncache method, so that you could bypass a deep uncache if needed.

Would something like this work? (written in browser, so might need tweaking). This should print all events sorted by date descending, but grouped by day and sorted by time ascending within the day. $allEvents = $pages->find("parent=/events/, sort=-date"); while($allEvents->count()) { $event = $allEvents->first(); $from = strtotime(date('Y-m-d 00:00', $event->getUnformatted('date'))); $to = strtotime("+1 day", $from); $events = $events->find("date>=$from, date<$to, sort=date"); echo "<h3>Events on " . date('F j, Y', $from) . "</h3>"; foreach($events as $event) { echo "<p><a href='$event->url'>$event->title</a> $event->date</p>"; $allEvents->remove($event); } }

This is a planned future addition, not yet implemented.

For pages that are only containers, I usually try to implement them as just a general listing page of the children so that there is something there if someone goes there. Basically, I like containers that behave as containers, listing what children they have. I also check the "hidden" box for the page, so that it stays out of navigation and searches, when desirable. Other strategies I've used are to: Not implement a template file, so the page throws a 404 when you access it; Have it redirect to either the first child, or it's immediate parent, or the homepage, using a $session->redirect().

When saving files to a page's path, Wanze's got the right trick there, but do it like this instead (which ensures the directory is created if it's not there already): $document->save($page->filesManager->path . 'myName.docx'); You might also want to add it to an existing files field on your page? $page->files->add($page->filesManager->path . 'myName.docx'); The above assumes your files field is named 'files'. For temporary, non-web accessible files, I usually save to /site/assets/cache/ $document->save($config->paths->cache . 'myName.docx'); If you need to store multiple files, it's best to have your module create it's own directory under /site/assets/cache/.

That's right. So if "{$page->adresse_detail}<br />\n" is literally the only thing being output by the template file, then that trailing "\n" will be stripped. But in the context of a larger HTML document, you wouldn't see the "\n" stripped.

This is why I always configure the settings on the "family" tab of each template before delivery, at least for sites that will ultimately be managed by a client. Presumably these same settings would be applicable for a Fieldtype/Inputfield module that pursues this multi-template repeater strategy. This was always one of my concerns with repeaters in the first place. It might be a bigger concern with a multi-template repeater. I don't see 1-screen page editors as something that should be scalable like this, at least not too far in quantity. Whereas the page tree is, and should be. Though at some point I would like to introduce pagination into repeaters for the admin UI, but a little worried that might encourage more bad repeater behavior. I do like repeaters, but it does seem like they get used for more things than they should, at least based on questions that have sometimes popped up in the forums. They introduce ambiguity into how to solve a particular problem. Before repeaters, it was always easy to answer how to solve any problem: use pages. After repeaters, the answers aren't as easy. Though for the places that repeaters are the right answer, they are a nice time saver. But I rarely find a use for them in my own projects. Shifting gears back to append ideas to my previous message, and maybe thinking of something different: one idea could be to have a checkbox on each template that says "Children tab shows: 1) links to child pages; 2) editors to child pages". If they select "2" then the children tab would show those iframe editors to each child page in a repeater-like format, and an add button, like mentioned in my previous post. It would show that rather than a PageList. An option for pagination would be a must have though.

ProcessWire only uses this method if you've enabled the $config->pagefileSecure option in your /site/config.php, and then only for files on access controlled or unpublished pages. I'm not a fan of this method of file delivery unless the file needs to be behind a wall for access control. Files are static assets that Apache can deliver without any PHP/MySQL overhead necessary. Delivering files through PHP consumes a lot of unnecessary resources. But if the file needs to be access controlled, then of course it's the way to go. But given that files really shouldn't be delivered by PHP unless necessary for security, these are the issues: Basically, I don't think direct file replacement is worth the compromise. Abstracting the file name to a tag (like mentioned in my prev message) is a clean compromise. Single file fields already support replacement (just drag and drop a new version on top of the old), but don't currently retain the filename unless you drop the same filename on top of it. So what I also think may be okay is letting the admin optionally specify a target filename for single-file fields with the file field settings. This would still be a cache concern, but would at least prevent recycling of old filenames.

…Until you do it from the API, Batcher or ImportPagesCSV.

PageLinkAbstractor isn't obsolete because its doing a little more than this solution is. PageLinkAbstractor is abstracting the links to page IDs, meaning it has the benefit of being able to keep links consistent with pages that move. I also don't see any potential conflict between the two, but if you are using PageLinkAbstractor, then there's no reason to enable the Markup/HTML option in your Textareas.

Any reason FancyAdmin isn't in the modules directory? Just re-watched the video, very nice.

I think this type of thing would be a very different animal from a repeater. While there are similarities, I think the functionality would be a lot simpler to build as its own thing rather than extending repeaters. Not to mention, I'm not sure I'd want to add that complexity to repeaters either. I can't envision a use for this type of field in the sites that I build for my clients, so I'm not likely to build it. But I can see how others would find it useful, I do agree that the idea is fun and interesting. Here's how I think it could be built without getting too complex: The Fieldtype itself would basically just be a FieldtypePage and may not need to be anything more. The Inputfield would be where all the action would happen, and I think a lot of it would be JS fun more than PHP code. When you click "add", the Javascript would append an <iframe> with a "src" attribute pointing to /processwire/page/add/?parent_id=123&modal=1 where "123" represents the predefined parent_id where these pages would go. That "modal=1" in there tells PW's admin to just display the editor and no header/footer, etc., making it perfect for this particular Inputfield. The "add" screen would prompt them for the template, as it already does, and let them add the page there. You could of course restrict the allowed the templates the usual way in the template family settings. Some JS would also have to be used to communicate between the <iframes>s and the parent window. Specifically, when the Save button is pressed in the parent window, you'd have JS trigger the save buttons in the other iframes (which you might choose to hide with JS/CSS). Likewise, JS would need to be used from the parent frame to examine the ID of the iframe/repeater items so that it could be saved to the FieldtypePage. There wouldn't be any need to add new API level stuff, because I think that what's provided by FieldtypePage already provides what this field would need. There would be some other issues to resolve as well, but ultimately the whole thing would be simpler to build than the repeaters if the author is willing to take advantage of iframes.

I pushed an update to the dev branch yesterday that should solve the issue of broken links in textarea/HTML fields when migrating a site between a subdirectory and root, and any other scenario that involves a change to the site's root path. This was previously solved by the the PageLinkAbstractor module, but I've always been on the hunt for a solid core solution. The solution I put in is really basic and simple, and I'm not 100% positive it's the right one, but here's what it does. When editing the settings for any Textarea field, you now have a "Content Type" setting: If you select "Markup/HTML" then it signals FieldtypeTextarea to look for certain attributes to convert when you save the page. Specifically, it's going to convert any local pointing <img src='...'> or <a href='...'> attributes to assume that the site's root is always "/" (at least from a DB storage perspective). Then whenever the field is loaded, it converts them back to the site's actual root. Using this method, any links or images placed in your TinyMCE/CKEditor textarea fields should continue working normally no matter where you move your site. Like PageLinkAbstractor, it doesn't retroactively apply to existing links. It only applies to links/images saved on pages after enabling the option. Unlike PageLinkAbstractor, it keeps the original code in a state that's still portable regardless of whether you later turn off the option or pull the text directly out of ProcessWire's DB. It's not yet had a lot of testing yet, so don't choose "Markup/HTML" unless you want to test it. As of 10 minutes ago, it's now compatible with TextareaLanguage as well.

If your browser is displaying something after hitting reload, then you are dealing with a browser cache. Your server may have some aggressive cache settings by default (via Apache). Either that, or those machines are configured to go through a caching proxy server is aggressive. But if it's something you can control, you can try modify these settings in your .htaccess file. You might find this post helpful too. I don't think that ProCache was the problem here, so you should turn it back on and just configure it how you want it. You can have it clear the cache every time a page is saved, for instance.

This is the first time I've seen PHP's settype() function in active use. You've got me curious–is there a reason why its necessary here? I think that what you are doing looks fine. But if you are looking for a code review, my opinion is that there's a lot of extra/unnecessary code and variable assignment here. For me, that makes it harder to read and comprehend what it's doing. If you find that it helps you to read it, then I that's a good reason to do it. But if it were me, I would probably shorten it up a bit like this: $cluepeople = $pages->get( "id=1344" ); $peopletypes = $pages->find( "parent=1582, include=hidden, sort=sort" ); foreach ( $peopletypes as $peopletype ) { echo "<h3>" . $peopletype->title . "</h3>"; foreach ( $cluepeople->person as $thisperson ) { if ( $peopletype->id == $thisperson->people_selector ) { echo $thisperson->title; } } } or this: $cluepeople = $pages->get( "id=1344" )->person; $peopletypes = $pages->find( "parent=1582, include=hidden, sort=sort" ); foreach ( $peopletypes as $peopletype ) { echo "<h3>" . $peopletype->title . "</h3>"; foreach($cluepeople->find("people_selector=$peopletype->id") as $person) { echo $person->title; } }

I'm really enjoying your posts too. You've got a gift with words – I find your writing really easy to follow and digest. All the right things explained in an accessible and succinct manner.

Make sure that you are more specific with your includes than this. If there was an "inc" directory off of the directory where your module is installed, then you'd want to do this: include($this->config->paths->MyAwesomeModule . 'inc/file.inc'); or this include(dirname(__FILE__) . '/inc/file.inc');

I agree. But so far it looks to me like CKEditor requires its plugins to be in its dedicated plugins directory, unlike TinyMCE which lets you specify a second external plugins directory. We need a /site/modules/ and all they have is a /wire/modules/, so to speak. Chances are there is a way to do it that I just don't know about yet, but I've not been able to find it so far.

SImply replacing a file with the same filename isn't usually a good idea because browser caches may not recognize it as a new file. Not to mention, the filename may have significance for the document, containing version numbers or the like. Basically, a replace by filename has a lot of drawbacks. You need a reference separate from the filename. In ProcessWire, that reference can be a page (for single file fields), or tags (for multiple document fields). For document centric sites, I usually have a dedicated space where file links go, rather than trying to manually link them in rich text editor fields. For instance, a sidebar with links to the files. If I need the links in body copy then I'm going to use a Hanna code there... but prefer to isolate file links to a dedicated and consistent space. If I want to list all the files on the current page with the tag "application" then I'll do this: <h3>Application Files</h3> <ul class='files'><?php foreach($page->files->findTag('application') as $file) { echo "<li><a href='$file->url'>$file->description</a></li>"; } ?></ul> If I want to pull all files with the tag "2013" (current year) from a page /shared/files/ then I'll do this: $year = date('Y'); $files = $pages->get('/shared/files/')->files->findTag($year); if(count($files)) { echo "<h3>$year Files</h3><ul class='files'>"; foreach($files as $file) echo "<li><a href='$file->url'>$file->description</a></li>"; echo "</ul>"; } If I have a page that I always want to print a link to the latest application form, rather than using tags, I might keep an individual page dedicated to that file (with a single file field) below my /shared/ page. $app = $pages->get('/shared/latest-application/'); if($app->file) { echo "<p><a href='$app->file->url'>Download latest application</a></p>"; } Any of this code could work just as well in a Hanna code as it could in a template file. The point here is to abstract files away from filenames, to pages or tags (at least on large document centric sites). This scales well, prevents possibility of broken links, and is simple and foolproof for the client.

If $page->viewable() is returning false, then it means one of the following: 1. the page it was given is unpublished 2. the page is in the trash 3. the page has no template file 4. the user has no access to it as a result of access control settings in the page's template, or one of it's parent templates. 5. A third party module is overriding the Page::viewable() function and changing the result. If you are logged in as superuser, then the page will always be viewable unless in the trash or has no template file. In your case, it sounds to me like it's most likely item 3 or 4 above. First, check that you actually have a /site/templates/vendor.php file. If you do, then look at the parent pages used by your pages using the "vendor" template. Do any of them define access?