ryan

Awesome, I look forward to checking it out. I actually haven't had any music playing here for months, so will enjoy this. Thanks.

Different CMSs use different terminology. My opinion is that I'm not comfortable letting another CMS define our terminology. I think we have to stick with the actual definitions of terms. So here is the dictionary: I can't think of any term that better describes what Templates are in ProcessWire: Oops, not that one, sorry This one: ...and... This is what Templates are in PW. A template in PW also has these components: - fields - file - access - urls - cache One large component of a template in PW is it's file. I think the term for that naturally should be: "template file". It could also be "output file", but a template file doesn't necessarily have to produce output so I don't want to use a term with any built-in limitations. Of course, the term "template file" also fits with the definitions above when qualified with "file". A template file also has a natural dependency of the fields used by the page (template) it is processing. The two are interconnected and part of the same thing. I think that changing the terminology or splitting these things up is unnecessary complexity. Some people may want to split them on occasion for technical reasons (and PW will let you in advanced mode), but I want to always target simplicity first. My opinion is that terminology like "template and "template file" fit the definitions and relate to each other in the appropriate manner. But I'll also qualify that by saying that it's also what I'm used to, and I think we all naturally prefer what we're used to.

No actually I think you are doing a good job of describing it, especially with the examples you just posted. You have complex access control needs and I think it would be difficult to describe in any language. Wow. This is all in one site? Stepping outside UA for a moment, I do wonder about possible efficiency, security and diversification benefits in having each association run off a separate database (smaller databases, less data, smaller indexes, faster execution, less chance of a problem in one affecting others). I'm only taking about separate databases, but sharing the code. This is more of an inquiry–how do you diversify these large scale needs? Stepping back into UA, I think that I understand now. It sounds like this is likely a complex UA setup regardless of where its implemented. If you were doing page-level UA, wouldn't you still need just as many (or potentially more?) access control points? I can see why you have so many templates in this scenario. But the main reason for that seems to be that there are 200 sites bundled into 1? If these were independent sites, they would have 2 access control points for teams, or 6 access control points for associations? That would seem much more manageable and more consistent with the intentions behind the current system. While it may be possible to implement, PW was admittedly not designed for managing the access control of 200 sites in one database (sounds like we need template pagination!). But I do think we can open the hood and add some custom modifications to make it sing in your situation. I would suggest that because your needs are pretty unique, we should collaborate on custom building an access control system specific to the needs of your company. I think we can make this a lot simpler just by focusing on this specific case with custom access control modules. I also wonder about abstracting the access control out of the site(s) completely, moving it to a shared web service (perhaps powered by PW) so that you could run the sites independently on separate databases, but allow the access control managers to control it in one place, just like the developers would edit the templates in one place. That way you could still get the efficiency and diversification benefits of separate databases. These are just ideas from an outsider that knows very little about the reality and scope of the needs there.

Fixed. I went ahead and made those pages non-searchable. I will wait till Jim finishes them.

In that case, with the 2.0 version, I would instruct them to use the existing link tool and paste in the file's URL as the href. Grabbing that file URL is as simple as right clicking on the filename in admin and selecting 'copy link'. This is how I always did it before adding the file selection to the link box in 2.1.

Wow that was fast! I look forward to trying this out tomorrow.

That em is to add emphasis to the children tab as a way to say "this page has children". The stylesheet gives a faint underline to provide that emphasis. So the search/replace would probably need to look for both versions... Emphasized and not emphasized (or use a regexp with preg_replace).

I'm actually thinking this won't work, though can't say for certain (haven't tried). But in 2.0 I think it's better to just link to the URL of the file you want. Right click on the filename in the admin, copy, then paste as the URL in the link tool. That's one approach. Another is to reserve some area of your site's design for listing/summarizing file attachments rather than relying on the editor to manually link them in the rich text editor (a good practice with or without 2.1). But of course the needs for every site are different and what makes sense in one site may not in another. PW 2.1 provides a little more flexibility here.

Okay hopefully an easy fix, I will try tomorrow. Thanks for finding it.

Good suggestions, I think these are even better (will use one of them).

If you don't want to have a view link and dont want to do it with access control another option is to just remove the template file used by that page (like section.php). If there is no file to produce output it won't provide a view link to it. Not sure if I answered exactly all that you were asking but will revisit in the morning.

Glad that works! I will move forward with the clone/duplicate API function here.

I fixed this bug over the weekend and it's already committed in 2.1. That's assuming this is the same one: https://github.com/ryancramerdesign/P21/issues/32

I have no idea what Spotify is, but it's late at night here and I want to put in my request now. I'll look up to find out what it is tomorrow.

I definitely don't want people to have to create any large amount of templates just for user access, so would want to find a solution for that. Though I'm still not sure that I understand the scenarios where a template needs to exist just for user access? Hundreds of templates just for UA (or even far less) would be a deal killer for sure, so we will definitely want to find an alternative there. Seriously, hundreds or even dozens of templates for ua?… I'm doing something wrong. Help me understand these access control scenarios–The more I can understand these types of access control scenarios I think the better. My thought is that we will offer page-level access control, but that the template-level access control provides us a better and more straightforward foundation for the core. That leaves us room to handle more complicated scenarios with needs targeted, specific solutions. I've always wanted to keep the core as simple as possible, primarily for the end-users, but also for long term maintenance and reliability of the software. Page level access control could be provided as something built-in, or as a special fieldtype that one can add to any template that then allows them to override the template-level access definitions. In such a case, template-level definitions would serve as starting points [defaults] rather than ending points. As much as I don't care for access being defined in the same place where it is granted or revoked, I'm certainly not opposed to providing this option where it makes things simpler. There are no sacred cows and the goal is always to make things simpler.

Antti, what version of PHP?

This is one area where costs speak louder than words. Give them an estimate for your time on how long you think it will take to invent a new sortable checkbox field type, then give them the cost for using something that already exists and is designed for this purpose. I have a feeling they will be enthusiastic about learning how to use the new field.

This problem has been fixed in the latest commit. The issue was actually that I moved some of this stuff into tabs. The tabs move some markup around, so any <script> tags in those tags get executed twice (once when page loaded, and again when tab draws). This is just something that happens in javascript when you move markup around. The solution was to remove <script> tags (via JS) before drawing the tabs. This is okay to do since those <script> tags had already been executed by the time they are removed. Thanks, Ryan

If I'm understanding correctly, your client actually wants sortable checkboxes? There is not a way to create two fields and have them share the same data. I should say that 100+ checkboxes is usually considered a problem from an interface perspective. Such a solution can't scale forever and at some point you'll just run out of memory (though, you'd have to scale quite a bit larger before that became a problem). For something that is going to keep growing, you need some form of pagination in there. The PageListSelectMultiple is something that will scale indefinitely and it does support sorting. I don't know of any other solution (in or outside of PW) that supports that scalability and sortability together in one field. If you wanted to create sortable checkboxes, you could always create a new Inputfield type for ProcessWire, and use it along with the Page reference fieldtype. This would require getting into some PHP and deeper into the PW API, but it is doable and we're always here to help you figure it out. If you go this route, I would probably use the InputfieldAsmSelect module as a starting point to adapt from.

Here is an example module for adding tabs to a page. I tried to cover a few things you might want to do after you've added the tab too, just as examples. If you want to download the module file (rather than copying/pasting), it is attached at the end of this message. <?php class PageTabExample extends WireData implements Module { /** * Provide information about this module to ProcessWire * */ public static function getModuleInfo() { return array( 'title' => 'Page Tab Example', 'summary' => 'Example of adding tabs to the page editor', 'version' => 001, 'permanent' => false, 'autoload' => true, 'singular' => true, ); } /** * Add the hook * */ public function init() { $this->addHookAfter("ProcessPageEdit::buildForm", $this, 'buildForm'); } /** * Hook called after PageEdit::buildForm is called * */ public function buildForm(HookEvent $event) { $form = $event->return; $this->example1($form); $this->example2($form); $event->return = $form; } /** * Add a simple tab to the page edit form * * Note that would technically add the tab link after the 'view' link on the form * See example2 to see how we get the view link at the end (assuming that's where you want it) * */ protected function example1($form) { // create the new tab $tab = new InputfieldWrapper(); $tab->attr('id', 'tabExample1'); $tab->attr('title', 'Example 1'); // create a general markup field as an example $field = $this->modules->get("InputfieldMarkup"); $field->attr('name', 'fieldExample1'); $field->label = "Example 1 field"; $field->attr('value', "<p>This can contain any markup you want</p>"); // add the field to the tab $tab->add($field); // add the tab to the form $form->add($tab); } /** * Add a tab before the 'view' link * * Also demonstrates setting or retrieving a value submitted to a field in the tab. * */ protected function example2($form) { // first we have to find and remove the view link, temporarily $view = $form->children('id=ProcessPageEditView')->first(); $form->remove($view); // create the tab $tab = new InputfieldWrapper(); $tab->attr('id', 'tabExample2'); $tab->attr('title', 'Example 2'); // now add our new tab and field $field = $this->modules->get("InputfieldTextarea"); $field->attr('name', 'fieldExample2'); $field->label = 'Example 2 field'; $field->description = "Enter some text. The text you enter won't get saved with the page, " . "so you'd have to do something with it in the same hook that displays this."; // since this isn't technically part of the page's fields, we have to // handle any input submitting to the field if we want it. if($this->input->post->fieldExample2 !== null) { $field->processInput($this->input->post); // we'll store in the temporary session var just an example. // using session just for example, you likely would save your value elsewhere. $this->session->fieldExample2 = $field->attr('value'); } else { // retrieve the value from the session var. $field->attr('value', $this->session->fieldExample2); } // add the field to the tab $tab->add($field); // add the tab to the form $form->add($tab); // now add that view link back to the form at the end $form->add($view); } } PageTabExample.module

@jbroussia: PW is writing all new fields when you do $page->save(). Since we set it's ID as 0 and called $page->setIsNew(true), we tricked ProcessWire into thinking it was a brand new page that it had never saved before. So from that point it is creating all new fields when you save it. Also, when we did "$cloned = clone $page;" it automatically cloned all the fields in memory too, so $page and $clone aren't sharing the same memory even for that moment. This occurs because PW implements PHP5's __clone() method and specifically sets up new fields at at that time. Admittedly, this is one of the first opportunities I've had to actually use it. You are right that file fields are different because they have corresponding files on the disk. PW needs to know where to place those files, and there's no way for it to know until the page has actually been saved (since the directories are based on the page's ID). So this is one of the details we would have to take care of with a $pages->clone function by saving/creating the page, then copying the files, then saving again.

Perhaps we shouldn't have a template called 'page' in the default profile. That was just the naming convention I used there to mean that it was for use by any generic/general/non-specific page. But it has no real relation to the PW term 'page', other than that. And thinking about it more, Drupal also has a template-file called 'page.php', which likewise means something different. You are right, this is a bit confusing. Thanks for pointing it out. I'm going to rename that 'page' template to something else (maybe 'general') in the default profile.

I'm assuming you are using PW 2.1 for all of this. But let me know if not. You are working with stuff that is somewhat different between PW 2.0 and 2.1, and I would definitely recommend sticking with 2.1 if you are creating new modules since we're just about to the point of making it the current stable version. You shouldn't have to clone any of the fields (or database entries), PW will do that for you. I just tested the example here and it did work for me (cloning the page and the fields). Though I should note I did have to add $cloned->setOutputFormatting(false); before I saved it. That would only be necessary if you put the code snippet in a template file, as I did. The only field I can think of that it would not currently work for is a file or image field... but I'll work on that. You don't have to clone any role/permission stuff because those are assigned at the template, not the page. So your clone will simply inherit the same roles from the template as the original did. Do you need the recursive/children cloning like jbroussia mentioned? If so let me know because I will want to get that new $pages->clone function in place this week so that you don't have to wait for this.

Well it just started happening on my computer this morning. So I'm able to reproduce it here now. No idea why it just started occurring, but I should be able to fix it now.

I may be confused, because think the previous example Antti posted should do this? The only thing I can think of is if you don't want it to expand the Gallery or Delta menus (assuming they have subpages) or if you want it to include/exclude certain items from the Contact menu. The example you posted is how you want it to look, is this correct? If so, can you post another example with how it appears using that treeMenu function? Also note in that treeMenu function you'll want to exclude this text "template!=post, template!=faq-item, template!=gallery", which is specific to the context Antti posted, but wouldn't be to yours. I think once we see what's different from your desired result you posted earlier, then it would be simpler for us to solve it. I think that you will just want to call that function like this: echo treeMenu($page);