thetuningspoon

I hate to keep harping on this, but managing and keeping track of the current OutputFormatting state on pages is still often a pain point for me during module development, and I'm wondering how others are handling this. I've been trying to follow the pattern in each of my functions of calling $of = $p->of(false) at the top of the function and setting it back to its prior state at the end of the function with $p->of($of). One of the big issues I come across is that I often need to turn off formatting for more than a single page, as I am often getting values from pages inside of page fields. For example, I might try to call $p->pageField->title, and expect that I am going to get an unformatted value because I turned off output formatting on $p, but in fact I get a formatted value because title is part of an entirely different page. I recently found out about $pages->setOutputFormatting(false), which apparently turns off formatting for ALL pages simultaneously. This function isn't listed in the cheatsheet and I couldn't find any documentation about it, so I'm not sure whether its use is recommended or not. I feel like the best workflow would be to turn off output formatting for all modules and "business logic" by default. I could then use getFormatted() on individual fields only when a formatted value is actually desired. For template files, on the other hand, I would like to have output formatting ON by default. I'm not sure how to best implement this, though, because PW doesn't explicitly turn on formatting for template files and generally assumes that it is on. I'd be interested in hearing what other module developers are doing.

Hi Cerulean. I definitely agree with your suggestion that the new page should be automatically selected when created. Unfortunately there isn't a straightforward way that I know of to do this, which is why I haven't done it yet. I am sure that it can be done (PageTable does something like it), but it will take me a while to figure out. Hopefully I will get some time to look at this soon since it is a feature I would like as well, and the "+New" link is a bit confusing without it. Thanks for the bug report. I'll look into this as well.

It should work. The modal will pop-up within the other modal. You just have to remember which one you're on when you click save I have built a CRM system which uses my AdminPageFieldEditLinks module to make it easy to view selected pages in a page field. This often leads to nested modal windows, so I've increased the default size of the modals to make this work better. It works okay, and though it can get awkward, it is still better than the alternative of having to break your workflow and find/open the page somewhere else. Edit: It would be nice if when more than one modal was nested, the nested modals would completely overlap and hide the previous, thus reducing the "tunneling" effect and only giving you only one "Save" button at a time to pick from.

I still write my CSS without a preprocessor... Is that weird now? I admittedly haven't really tried any of the preprocessors (although I have looked into them), but at this point I prefer to use plain CSS because I can see exactly what code I'm producing and base how I architect my CSS off of that. I'll have to look more into this gulp n' grunt stuff...

Interesting. So then, if I want to run some processing on a field each time it's saved (whether individually or along with an entire page through a $page->save()), how would I do that? Edit: Now that you mention it, I do recall seeing that note in Page.php. It doesn't really indicate whether or not hooking into one or the other will cause it to run in the other instance, but after doing some testing I see that saving a field individually will not trigger the save hook. I'm still foggy on how to best accomplish what I'm trying to do.

I have a field which I want to format whenever a page is saved. So if I hook before Pages::save or Pages::saveReady, I can check for the field and the processing is performed whenever I call $page->save(); My question is, what happens when I save just a field using $page->save($field) or $page->setAndSave($field,'value')? Am I correct in assuming that the hook is run in either case?

I think I know what you mean. Try changing line 119 in AdminPageFieldEditLinks.module from this: $newPageParent = $event->object->newPageParent ?: $event->object->parent_id; to this: $newPageParent = $event->object->newPageParent; Now just make sure that you are specifying a particular template and don't select a parent for new pages. Now when you click "New" it should now ask you where you want to put the new page, based on the template's family settings. I haven't tested, so let me know if that works.

I'm getting output formatting errors even when I've called of(false) on a page earlier on in my script. Is there something other than calling of(true) that could cause a page's output formatting status to turn back on during the same request? (saving another page, perhaps?) EDIT: Okay, here's one example out of many I've run into: I have one template that includes two other files (one for a "controller" and one for the "view"/markup output). If I call $page->of(false) at the bottom of the first file and then check it's status with $page->of() in the second, output formatting is back on again. However, if I call $page->of(false) in the second file right before I output the status, then it shows it as off, as you would expect. EDIT #2: Just tried this again on a separate install. This time I tried turning off output formatting in a head.inc file and then echoed $page->of() in the main template file. Once again, output formatting is back on in the template file. But if I turn off output formatting in the template file itself (as long as it is after the include statement), it remains off. EDIT #3: I was able to narrow this particular issue down to the MarkupSimpleNavigation module, which must be switching outputformatting back on somewhere in its code without resetting the state after that. Let's see if I can narrow down my other issues....

What would you expect $page->children->field to return? An array containing the values of the field for every child page? Or are you thinking it should return true if any of the children have that field populated?

Thanks BernhardB. Have you had a chance to test the module with the new asmselect, and does it still work okay? I haven't had a chance to test the latest dev yet.

Any opinion on the "View" vs. "Edit" link label? Originally I had just changed it to "View" for one of my projects, but then I realized this might be clearer for the majority of applications, since "Edit" could imply editing the field itself rather than the selected page(s).

Hi BernhardB, glad you like it! This feature has been indispensable on my own projects as well. If I understand correctly, it sounds like you need the ability to alter the parent page of new items based on the location of the current field in the page tree. Right now if you leave the parent option blank it should give you the option of where you want to add the page each time you create a new one. But I know this isn't ideal for what you want to do. I'll look into creating a Custom PHP field for that. I'm not completely sure if it's even possible, but my guess is that it shouldn't be too hard if I can look at how Ryan did it. I agree that an unselect button would be nice. I haven't looked into how the page list select works under the hood, but it sounds like that might be a fun challenge if I can find the time to look into it. It might be as simple as adding a button and overlaying a bit of javascript to trigger the other button that's hidden in the list.

Ok, updates! Regular asm inputfields now work dynamically without the need for a page save Compatible with the new singular autocomplete fields Links are now fully configurable on a field-by-field basis Implemented preliminary "Add New" functionality to enable adding pages via modal window right from the field Changed "Edit" link labels to "View" (just my preference... but maybe this could be made configurable down the road) Code cleanup and optimization Note that after you upgrade you may have to re-set your page fields (just the edit link checkbox, not the whole field).

Hi BernhardB, I'm aware of the issue and actually have an update to support the single page autocompletes which I'm already using on one of my projects, but haven't gotten around to merging it with the Github project yet. Believe it or not, I've also been experimenting with adding an "add new" link just like you suggested here. The biggest problem I'm having with this is figuring out how to automatically populate the field with this new page once it's published. I'll have to study how Ryan does this when creating a new field in the template editor.

Just to confirm, is the page field you're working with an inputfieldSelect (drop down html select) or something else? Currently I need to update the module to work with Ryan's new singular inputfieldAutocomplete, but it sounds like this is a different issue.

I have observed clients having issues knowing which "New" button to use, but I'm not sure how this could be made more intuitive. It would be interesting to hear some different ideas. That said, the page tree is very intuitive, in my opinion. Most CMSs require you to do a two step process: create a page in some sort of massive "content bin" and then create a menu item that links to it. Usually the interface for creating the item is far less elegant than PW's page tree. In my experience, PW is a breath of fresh air for clients. You do have to put in some effort if you want to make the experience as seamless for clients as possible. In my opinion, the "Family" settings for templates is not optional. You really need to put the time in to set these-- Clients shouldn't be able to create a blog entry or news article outside of the blog or news section. That's just asking for trouble! Also, you can do a lot by setting access/permissions on your templates. You can prevent certain pages from being modified, while still allowing access to modify their children by giving the child templates different access settings. You can also lock pages. I really recommend playing around with some of these settings and logging in with your editor permissions to test them out until you get things fool-proof.

I'm not familiar with the particular module, but is this the first time you tried installing the module, or are you trying to re-install it?

I was just looking through the Pages::save method and it does appear that PW automatically turns off outputFormatting before it saves the fields. So I think I understand now what's happening here a little better. It's true that outputFormatting has nothing to do with input. However, a Page object will apply outputFormatting when you call one of its fields (properties), even if the field has never been saved to the database. When a page object is later saved, the save() function loops through each field and writes it to the database. In other words, it gets its output. So outputFormatting must be turned off when it does this or it will not save the value that you actually input. So that makes sense. But I still don't understand why PW requires ME to set of(false) if the save() method already does this. Because I very rarely need to retrieve a value from a field, modify it, and set it again. So I would appreciate it if PW didn't crash in the cases where I just want to save a new value... Edit: Also, in those cases where I do need to retrieve an unformatted value, I would prefer if I could specifically use $page->getUnformatted('field_name'), modify the value, and then do $page->field_name = '$modifiedValue' and $page->save() instead of having to store the current state of of(), turn it off, and then restore the previous state.

Thanks sforsman. From reading Adam's original post I thought there might be more to it than that. That is awesome. So everywhere that a page is instantiated in PW, it will use the alternate class for that page? I'll have to try it out.

See, I get that, but I still don't get it. If what you're saying is correct, it seems like that the only time output formatting should have to be turned off is in the case that you are getting an existing value, modifying it, and setting it back to the same field. (And even then it seems this should be completely up to the dev's discretion, since they might actually want the formatted value for some reason). But most of the time when I am editing a field from the api I am completely overwriting the value with a new one, in which case we are only dealing only with input so output formatting should not be a concern.

https://processwire.com/talk/topic/10485-simplify-output-formatting-when-saving-pages-via-the-api/

I've discovered the "ProcessPageAdd" hack as well

You don't need "home" and you need the name of the "Admin" page in it's place. By default, the name of the Admin page is "processwire" so you would want: parent=/processwire/repeaters/for-field-112/

Hi Richard. Guess what? The repeater rows ARE pages They are stored under the Admin area in the page tree. So they could technically be selected in a page field, but I'm not sure how the titles would be handled or how you would select for all pages if the repeater appears on multiple pages. It would probably be a bit clunky, but you might be able to get it to work they way you want if you play around with it. I think the better way to go would be using a PageTable field, and then hiding the page list somewhere out of the way in the page tree. You would have more control that way. But then you'd have to use the modal windows for updating values, which may not be what you want. EDIT: Since you can specify a field other than the title to be visible in the Page select input and all of the repeater pages that use the same repeater field are (I think) stored together, maybe repeaters would be the more elegant solution for this after all. Just keep in mind that "plain old pages" are always the more flexible and scalable option if your needs change down the road.

I've been using Ryan's method here of adding hooks instead of extending the Page class, but as my applications grow larger I'm wishing that I had some of the benefits of organizing my code into subclasses and not having to write all of my methods as hooks, which can be a bit of an added pain sometimes (having to pull the object, parameters and check for the page template each time). Ryan- If one were to extend the Page class instead of hooking to it, would you have a recommended way of doing so?