ryan

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.

PW 2.3.2+ also includes a way to update modules from the admin, like ModulesManager. But the benefit of updating with ModulesManager is that it can tell you all the modules that have updates available, without you having to check them individually.

Unfortunately I can't listen to music when coding at all. I'm with dragan in that the only thing I can handle is ambient or classical stuff, and even that can be too much distraction. The only time I do it is if there is some other noise that is more distracting that I need to muffle out. I do like listening to music when working in Photoshop or doing some kind of data entry, content population, etc.

That usually means there is a PHP error getting shown, which is preventing jQuery from parsing the JSON returned by ProcessPageList. The best way to see the error is to go to your JS browser tools and click on the "network" tab, then examine the request–you should see an error message followed by some JSON.

That's an excellent suggestion. I'm honestly not yet sure how to implement it though. I've gone ahead and added a "data-language" attribute, with the language ID, to the LanguageSupport wrapper that goes around each multi-language field. The next step is to get the TinyMCE and CKEditor pwlink.js plugins to pull the language ID from the wrapper–this is the part I can't figure out yet. Once we've got that, the TinyMCE/CKEditor plugins can easily bundle it into the iframe/model request URL as a GET variable. Then the ProcessPageEditLink.module can detect and use it from there.

Okay it sounds like it must be part of TinyMCE's validation rules. In that case it's just a matter of finding what configuration directive needs to be supplied (or removed from) TinyMCE in order to change that behavior. I am guessing you will be able to find it in their documentation, but if you can't, you could always make a [[nbsp]] Hanna code too.

See this Comments Fieldtype documentation page sections on customizing output and styling output. While it makes it easier, you don't actually have to use the built in methods for rendering the comments list or form. You can create your own markup entirely if preferred. However, I do think it would be worthwhile to copy or extend ProcessWire's /wire/modules/Fieldtype/FieldtypeComments/CommentForm.php file to your own class (MyCommentForm) in /site/templates/. When you want to render your form, you would do this: include("./MyCommentForm.php"); $form = new MyCommentForm($page, $page->comments); echo $form->render();

It's best that the directory name and filename don't change after it's installed. It should be uninstalled first, deleted, then re-installed, if such things change. I It looks like I've got a disconnect between the class name listed on the modules directory and the repository name at GitHub. The class name listed in the modules directory is what should be used for the directory name (TextformatterHannaCode). Though you certainly could install it under ProcessHannaCode too, but this would confuse the modules manager (including the built-in one). So I recommend using a folder name of TextformatterHannaCode for compatibility with the modules directory.

It works on the dev branch. That's assuming you are using the built-in language support modules (LanguageSupport, LanguageSupportFields, LanguageSupportPageNames). Though I am still working out a bug where the multi-language page names don't get copied over to the clone, so don't bother setting the non-default language page names until after the clone is made.

Sounds like you have pretty unique needs here, and I understand now – your approach does make sense given the context. I think Kongondo's ideas are good here, and I will keep thinking about how we might support separate labels in the asmSelect list there for the future.

You can just do: if($field->type == 'FieldtypeText'. But it looks like you are intending to operate on the 'title' field? In that case, I think what you really want is FieldtypePageTitle. The "+" won't concatenate strings in PHP. You want to use "." instead. With regard to everything else, it looks like you are on the right track. However, it might make more sense for you to just implement a Textformatter module instead, as this is exactly what they are designed for: /site/modules/TextformatterOzwim.module class TextformatterOwzim extends Textformatter { public static function getModuleInfo() { return array('title'=>'Ozwim','version'=>1,'summary'=>'Ozwim summary'); } public function formatValue($page, $field, &$value) { $value .= "- modified page title FTW"; } } Once you've got that, install it and select it as the Textformatter for your page title field (or whatever field you want to apply it to).

I figured it out. Since PageRender::renderPage is providing the rendered output in $event->return; rather than the function returning it (since it is actually a hook to a non-existent Page::render), then you have to do the same. As a result, this code in your before hook function should work: $otherEvent = $event->arguments(0); // grab event provided to PageRender::renderPage $otherEvent->return = "<p>Hello World</p>"; // plug in our value $event->replace = true; // prevent PageRender::renderPage from being called

In your case, if your before hook replaces PageRender::renderPage, you should be able to just echo your output directly. You don't need to exit or stop execution. Meanwhile, I will look into making $event->return; work for before hooks with $event->replace = true;

This Page::render is kind of a special case, because there isn't actually a Page::render() method if you look in the Page class. It is itself a hook added by the PageRender.module. So you can't replace it since the method doesn't actually exist. Instead, you'd have to hook the source of that Page::render hook, which is actually: PageRender::renderPage.

That may be a good idea, but this module probably isn't the right one for it. I'm using some techniques with it that wouldn't seem to be applicable to situations other than this module. The FieldtypeMapMarker (which also includes its own Inputfield) is one I originally made as a tutorial on how to make your own Fieldtypes/Inputfields. I still think it's one of the best examples, though there may be others that are equally good or better now. But without knowing of one, I'd still suggest the MapMarker Fieldtype as a good example.

In my experience, clients understand and accept very well when you tell them that you created some constrains on purpose. The important is that they look at their website and their friend's website and see why theirs looks much better. I'm not implying that we should be offering all the control of Word to the client. I totally agree with using and communicating the constraints. Our RTE's are very constrained in their default configuration, relative to most other CMSs using RTEs, and that's of course intentional. I've spent a lot of my development career being opposed to web-based RTEs. But over time have come around to feeling that a constrained RTE is about the ideal situation… clients have a high level of comfort with it, as a result of it having similarities to desktop RTEs (Word, etc.). I've now had clients using TinyMCE for years (and now CKEditor) and I like the fact that it reduces the support burden a lot. A well constrained, quality RTE is going to make it very difficult for a client to break things. I'm especially a fan of CKEditor 4 paired with HTMLPurifier, for this reason. In the past, I've tried to get clients to rally behind Markdown. Dictator CMS (which had no RTE) was built around it, for example. I like Markdown, but it unfortunately takes a special client to adopt and like Markdown, and a lot of extra support burden for me. HTML is allowed in Markdown as part of the standard, and this is inevitably what clients resort to when they can't figure something out... which creates a new and perhaps worse kind of mess. GitHub-flavored Markdown seems to be a improvement in this respect. I'm sure there are both benefits and drawbacks to the blocks approach that's been mentioned, a compromise, like anything else. A CMS built around that is conceptually distant from ProcessWire, as we aim to keep layout concerns and markup generation out of the content management. In our environment, there is a clear separation between where and how things are output, versus management of content that is contained. Though for those cases where people do find the concept beneficial, ProcessWire also aims to be flexible, more than anything.