ryan

I think that doing a hook replacement of buildFormRoles should remove that entirely. If you hook in before and set it to replace, then it'll never even call PageEdit's buildFormRoles method. Set $event->return to return a blank InputfieldWrapper, InputfieldHidden or InpufieldMarkup. public function hookBeforeBuildFormRoles($event) { $event->replace = true; $event->return = new InputfieldWrapper(); } (on mobile so can't test at the moment, but think that should work)

Strange, I replied to this yesterday and now don't see my message. I'm wondering if I forgot to hit post or something (or maybe I'm losing it?) Anyway I fixed this yesterday morning so searching for CSV should now work. I switched it to use '%' and added the summary, description, class_name and instructions fields to the search.

I'm thinking it shouldn't affect performance too much, but haven't tried -- I'm curious what you find here. Since the primary need is just to not show the pages in PageList, you could set it to do this only when ProcessPageList is active: if(wire('page')->process == 'ProcessPageList') { } No problem. I've just made it hookable and will push to GitHub within the next hour (along with some other minor updates).

I agree with Teppo, this is really a great site.

Thanks for testing it, I've committed the changes so they now appear in 2.2.6.

Thanks Soma, this clarified it for me.

Soma, this looks cool, but I'm not sure I fully understand exactly what it does. I've been looking at the code and the function arguments for a bit here, as well as the other thread, and a little confused?

It sounds like the template you are trying to retrieve does not exist. I have a feeling there are some extra characters in $page->form_name, and that's why Soma's suggest to trim() and strip_tags() may be a good one. It's very possible you've got some textformatter on there putting "<p>" tags around it, or doing something. So make sure no textformatters are manipulating the field (can be seen on the details page). You can examine exactly what is in $page->form_name by doing this: echo "'" . htmlentities($page->form_name) . "'"; I'm guessing you've got something in there more than just the form_name, or perhaps it's completely blank.

I'm good with a toggle. I don't want to change the existing default behavior, just because it's been there awhile, and some people may be relying on it (including me). So dont want to produce any surprises. But I've added a toggle called 'arrayToCSV' that you can put in the $options. If you set that to false, then it'll put it in the format that you prefer. I've attached a copy of this file. Can you test to confirm that this works the way you were thinking and let me know? If all looks good, I'll commit it to the source. MarkupPagerNav.module

Glad to hear you are making progress with this! ProcessWire handles the template-based permission checking at the DB query level, so something like PageList assumes that anything it gets is okay to include in the output. Having the permission check at the DB query level is necessary to ensure that things like pagination and 'total' counting are accurate. Though if you aren't often paginating 'pages with permission' vs. 'pages without permission', in the same list, then this may not be a concern. Since PageList is going to show whatever it gets from $pages->find(), I think your best bet is to hook after $pages->find() and specifically remove the pages the user doesn't have access to: public function hookPagesFind(HookEvent $event) { $items = $event->return; foreach($items as $item) { if($page doesn't have the role(s) you want) { $items->remove($item); } } $event->return = $items; } The main thing to note here is that since you are performing this filtering after find(), the quantity of pages returned may be less than what you've specified in your "limit=n" selector.

Those commented translations in default.php are kind of a placeholder/short cut, and you are seeing a side effect of it. Typically translatable text consists of static text in a file. But the translation being done in this instance is actually on dynamic text. So the commented translation calls are picked up by the parser as translatable copy, but obviously those function calls never execute (since they are commented). Instead, the admin template runs the navigation titles through the translation function, with dynamic text (actual page titles). So if it encounters one of those placeholder words/phrases in a page title, a substitute translation will get used when available. When you removed the __("Templates") line, ProcessWire considers that abandoned since it no longer appears in the file. But "abandoned" is a runtime state, not a permanent one. That state exists only to notify you during translation time what words/phrases no longer appear in the file. The file still requested a translation for that word "Templates" at runtime, and it found that there was one, so it delivered it. You would have had to delete the abandoned translation to fully get rid of it.

I also like how if you click on 'contact' it pops out a bar from the top. A nice touch.

Delete the ones you want to replace and drag them into the file field. I suppose you could also replace them via FTP, but you wouldn't want to do that for new files. I understand it would be ideal to just be able to drop and replace in 1 shot, but don't have an easy answer for that yet. I think they would have to be split into two separate file fields to do this. Might be a good thing to add during one of the next updates to LanguageSupport. But this would provide some separation between core and custom stuff, making it easier to maintain, which is what I think you are alluding to. Sounds good to me.

Why so many template files? Is there any duplication between what you are doing from one template file and another? If so, remember never to repeat yourself and keep reusable stuff in separate includes, functions or modules. Also consider whether the different template needs might instead translate to stylesheets. But I know you have a good handle on all this stuff, so going to assume you really do need a lot of template files. In that case, I would suggest doing something like you indicated and considering your templates to be something more like template groups instead. Create a structure of pages that represent your "sub templates". Make them selectable, so that when you edit a template, you'll have a select box where you can choose a sub-template (with a field named sub_template). You can translate that page selection to a filename off a subdirectory in your /site/templates/ directory. For instance, lets say you are creating a page with template "news" and you want to have sub-templates of cnn, nbc and abc. You'd have a page structure like this to represent them: /sub-templates/ /news/ /cnn/ /nbc/ /abc/ And a template file structure like this to represent them: /site/templates/news.php /news/ cnn.php nbc.php abc.php Your news.php file might look like this: include("./news/{$page->sub_template->name}.php"); What I'm trying to get at here is that you can create a structure of pages to represent a structure of templates.

This is a fun question to answer, so thanks for asking it. It really gets down to much of the motivation behind the system. For me it really comes down to time. Time is the most important thing to me. I'm getting old and need to focus on the things that give me more time, and that's what it's all geared around. For others, it's money. But time is money. Either way, you have to ask: "what is saving me time?" That's all you need to know to answer the question. But here's the long version: How much time does it save you to use a template engine vs. PHP API? I would suggest that using a template engine saves you zero time (maybe even costs time) vs. using a clean PHP API like in ProcessWire. Ultimately you are just typing different characters with a template engine, in about the same quantity, to do the same thing (example). Nor is a template engine performing any heavy logic, thinking or processing behind the scenes… it's mainly just substituting one thing for another. It's not saving you any time or mental/logical energy. It's this whole abstraction layer taking up space that isn't contributing anything to the bottom line. So the benefits of a template engine aren't very clear, relative to using something like ProcessWire's API. And I don't think it matters whether you know PHP or not, as the learning curve is identical between PHP and a template engine, for accomplishing the same things. The only difference is that PHP will go much farther, when/if you want it to. Then look at the amount of time it would take you to construct raw DB queries (or through some abstraction layer like ActiveRecord). A simple selector that you write in a few seconds translates to a rather long and complicated SQL query that might have taken quite some time to create and optimize manually. Whether in ProcessWire or somewhere else, to create the SQL query, you would have had to maintain internal knowledge of the database, tables involved, indexes, left and right joins, orders, grouping, limits, security and much more… So I would suggest that ProcessWire's selector syntax is saving HUGE amounts of time (and thus cost) by abstracting away a whole lot of technical details and optimization. At the same time, it's part of a larger system that has also abstracted away the complexities of DB design and optimization, and brought it all into the context and thinking of a website. You don't need to know anything about databases or indexes, or that they even exist. I would also suggest that ProcessWire gives one the impression that they can easily pluck data from anywhere in their site as if it was already in memory… and in the context of a website, not a database. In terms of time and cost savings, is there any comparison between this and a template engine?

Just want to make sure I've got it written down as to what specifically would help: Addition of an option to support intentionally-empty translations, and not have them count towards the untranslated count. Addition of a tool that finds all translatable files and also calls out those that don't have any translations (i.e. new files) Addition of a tool that bundles all translation files into a ZIP or something like that, ready for download. Does this sound right, or anything else? I can't get started on these right away, but thought it would be good to get them written down so they can become part of the roadmap at least.

I've never even heard of allow_call_time_pass_reference, so haven't ever put it into PW's code anywhere. Though wondering if some kind of '&' usage is triggering it or something. Is there any specific page that it's occurring on, or does it appear random? I'm also wondering PHP might be picking this up from a php.ini or .htaccess file somewhere on your server (given that it says line 0 of Unknown)?

Nico I couldn't duplicate here, so probably need to know more specifically what you were trying to change in the TinyMCE settings. I tried adding h1 to my theme_advanced_blockformats and it worked just fine with the two languages I tested it with in a TextareaLanguage field. The only thing I could see from your screenshot is that you had the theme_advanced_blockformats pasted into your theme_advanced_buttons. As far as I know, those don't represent valid button tags for TinyMCE. But just in case, I went and tried them myself both with Textarea and TextareaLanguage, and they don't produce buttons in either... so I'm assuming they aren't valid. But maybe I'm not looking at the right thing in your screenshot. Let me know how to see the error you are talking about.

Thanks Nik! I have corrected that and push the update to GitHub.

Since they already have to be translated for the module file, it's unnecessary duplication. Though I'm not opposed to duplication if it makes things simpler/faster for everyone. But since this one is specific to dropdowns in this admin theme (something not in all admin themes), maybe it would be better for it to grab the translated module titles rather than the page titles. Basically like this: foreach($children as $p) { if($p->process) { $info = wire('modules')->getModuleInfo($p->process); $title = $info['title']; } else { $title = $p->title; } echo "<li><a href='{$p->url}'>$title</a></li>"; } The other advantage of this approach is that it works with any modules, not just ones that have been predefined in default.php.

The disadvantage with uniqid() is that its output is predictable since the value returned is based on the current timestamp. So on the surface, it seems there's possibility for that to be exploited, although it might be challenging. The password generation I put in the example above is based all around random characters, which aren't predictable other than the set which they come from (a-z2-9) and the length (between 9 and 12). I think this is pretty strong. However, the security of it could be increased by adding more to the set of possible characters (punctuation, upper/lower, etc.) and increasing the possible length range, like up to 30 characters or something. I opted to limit the character set and exclude the letters that are easily confused with each other, like "o O 0" and "i I l 1", just in case people are hand-typing (rather than copy/pasting)… less support burden. Another thing I might add to the code would be to make it only work with users of a certain role. But that would be pretty site-specific, so left it out here.

I think that it would be fine to do it with PW pages, and have been played around with doing it that way myself (and may pursue it further in the future). But Pete is right that since comments are a fixed format, and potentially more vast than your site's content, it's more efficient for them to be in their own tables, separate from PW's pages. And that's the reason why PW's comments are their own thing, rather than pages. However, I think there are plenty of benefits to having them as pages too, but it is a bit of a compromise in efficiency for flexibility. And perhaps a worthwhile one. I'd say go for it. But ideally don't have any crossover with the fields you use for comments, and the fields you use on the rest of your site. That will ensure that the quantity/scale of the fields used by comments doesn't introduce any potential bottlenecks in your site's pages.

There are other ways to prevent a double post, but there are actually a few other reasons why I want to do a redirect after a successful comment submission, so figured that's the method we'd use. That's not to say we might also add another method of duplicate detection though. That's the plan, though Markdown is not anonymous-user safe, unless we can get a version like the one GitHub is using. Both BBCode and Textile provide modes that are anon-user safe, so they would be good candidates to use with a comments field.

The phrases from that screenshot can be translated via these files: /wire/modules/Process/ProcessTemplate/ProcessTemplate.module /wire/modules/Process/ProcessField/ProcessField.module /wire/modules/Process/ProcessUser/ProcessUser.module /wire/modules/Process/ProcessRole/ProcessRole.module /wire/modules/Process/ProcessPermission/ProcessPermission.module Looks like I still need to make the "Languages" one translatable… ironic

That makes sense, I'm fine with switching it from name to label. Though wondering if maybe I should just change it to "Updated %d fields" so that it all goes out in one message (and maybe reserve the individual change lines for debug mode or something).