ryan

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?

Because permission inheritance is determined at runtime. Two pages using the same template can inherit different permissions based on what templates their parent pages are using. To put it differently: when a page is using a template that does not define access, then that page is going to inherit the access from the nearest parent page using a template that does define access. As a result, if you only define access on your homepage template (which is the default setting) then those access settings are inherited throughout the entire site. But then if you had a page called /private-stuff/ that was using a template called "private", and that template defined access, then any pages below /private-stuff/ would inherit the access defined on the "private" template. The only exception would be if one of those pages used another template that itself defined a different access.

Last thing I want to add is that ProCache is not active when a user is logged in, meaning their requests are all dynamic. Template cache works the same, though can be configured to cache requests for logged in users. MarkupCache is always cached, and doesn't care if the user is logged in or not.

I personally do what Apeisa suggested: use ProCache with occasional bits of MarkupCache where it makes sense (like caching renders of large <select> lists or that sort of stuff). Though keep in mind, MarkupCache is only used when ProCache isn't. So MarkupCache is only there to speed up some elements in non-cached page renders. Many sites simply don't have anything that benefits form MarkupCache, so don't make it part of your strategy to use MarkupCache until you find a need for it. ProCache won't be used on any POST requests, so that it doesn't interfere with front-end forms, logins, etc. (Template cache can also be configured to do this). I also usually configure ProCache to not run when specific GET variables are present (or all GET variables, if preferred). This enables you to consider any request containing GET or POST variables as truly dynamic (never cached), and any requests without them as potentially cached requests. ProCache can also cache requests that use URL segments. As a result, in order to increase the pool of potentially cached pages, I will use URL segments instead of GET variables for some high volume requests. Given all this, my suggestion is to use ProCache to cache the default view of all pages where possible. But consider any requests containing POST/GET variables as non-cached, dynamic requests. And if you have any components in your page that are slow to render (like a giant navigation tree or something) then use MarkupCache with those. If your cached pages have elements that need to change daily, hourly, every 10 minutes, etc., then set your ProCache expiration time accordingly. Using Javascript for some elements also enables you to make a cached request look dynamic.

The FormBuilder module also supports front-end file/image uploads in a secure manner. FormTemplateProcessor was just made as a proof of concept for people to adapt and build upon where useful. Whereas FormBuilder is a full system.

I think that some code like this in your /site/templates/admin.php would probably solve it. I haven't tried it (just wrote it in the forum), but I think it would work. $pages->addHook('saveReady', null, 'hookSaveReady'); function hookSaveReady($event) { $page = $event->arguments(0); if($page->id) return; // not a new page if(!$page->is(Page::statusUnpublished)) return; // page is already published $admin = wire('pages')->get(wire('config')->adminRootPageID); if($page->parents->has($admin)) return; // leave pages in admin alone $page->removeStatus(Page::statusUnpublished); // remove unpublished status. }

That error messages sounds like you are trying to use a file or image field with FormTemplateProcessor, and file/image fields aren't supported with it. The error message should go away if you remove the file/image field.

I'm thinking this change might be a good idea there? // build a selector to find matching pagerefs // @todo should $selector include check_access=0 or even include=all? $selector = 'include=hidden, '; if($field->findPagesSelector) { // remove the existing include=hidden, only if selector specifies a different include=something if(strpos($field->findPagesSelector, 'include=') !== false) $selector = ''; $selector .= $field->findPagesSelector . ", "; }

Are you going to add this one to the modules directory or still working on it? Just noticed it wasn't there, but seems like it should be (nice work!).

What you are looking for is probably $page->localName($user->language). The LanguageSupportPageNames module modifies the output of $page->path() / $page->url(), but not $page->name. That's because it's kind of a primary identifier for a page that needs to stay consistent at runtime regardless of language.

labelFieldName renders unformatted in order to keep anything from potentially breaking in the admin. It routes all output through htmlentities() just to ensure its suitable for display. That's the only safe way to do it. The workaround you mentioned is the correct way to do it with the Concatenate Fieldtype.