thetuningspoon

Another convert!

I like mine: https://github.com/thetuningspoon/SI-Layout

I enthusiastically approve of this feature request

Ah, great point, kixe. I hadn't even considered permissions since it hasn't been an issue in any of my use cases yet. If you have a github account, would you mind adding this as an issue? Thanks.

I didn't see this thread before, but I came up with an alternate solution to this as well: https://processwire.com/talk/topic/11930-module-modalception/

Modalception for ProcessWire GitHub: https://github.com/thetuningspoon/AdminModalception Direct Download: https://github.com/thetuningspoon/AdminModalception/archive/master.zip Modalception improves the usability of ProcessWire's modal dialog/popup windows when opened from within another modal window. The parent window is expanded to take up the full screen behind it so that additional modals can be opened without the inner windows becoming progressively smaller and less usable. The outer windows' toolbars are hidden from the user to help reduce confusion. * Screencap also features the Page Field Edit Links module

New in version 3.0 Removes the limitations of the previous releases! Now compatible with all Inputfield types including Select, SelectMultiple, Checkboxes, Radios, AsmSelect, PageListSelect, PageListSelectMultiple, and PageAutocomplete. When using the create new page feature, new pages are added to the field and selected automatically as soon as the modal is closed. No further input is required from the user. The "View" and "+ New" strings are now translatable The add new page links may be enabled independent of the view/edit links Code performance improvements GitHub: https://github.com/thetuningspoon/AdminPageFieldEditLinks Direct Download: https://github.com/thetuningspoon/AdminPageFieldEditLinks/archive/master.zip I ended up using a combination of different methods for populating the field with the new page once it's created. Some of the input types were fairly easy and could be updated without reloading the field, while others required some pretty wild code acrobatics, taking advantage of Ryan's new AJAX reload and repopulating the input with pages that were already selected but not yet saved. Please let me know if you run into any bugs. This was built mainly in Chrome with limited testing outside of it so far, so I expect some issues. I hope you guys enjoy the new features! Let me know if you have other suggestions for further enhancements.

I'm close to the finish line on this latest update. I've added support for ALL types of inputfields as well as automatic selection of a new page when it's added. I'm still working on the autocomplete inputfield and a few optimizations and then I will push the changes to GitHub.

Yes, see the next two posts in that thread Your solution is helpful but still requires the page with the PageTable to be viewed in the editor before the item actually gets added to it.

I've found that in every case I've wanted to have the PageTable pages stored in a visible part of the page tree, I run into issues where the client tries to add a page in the page tree and it isn't added in the PageTable automatically, so I've taken to keeping all of my PageTable pages hidden anyway to avoid confusion. It seems that in these cases I'm not really looking for a separate field to store page references, but just a different interface for managing the existing page tree that can be embedded in the page edit view.

I think one enhancement that would really help pageTable stand out in certain use cases would be if it had the ability to search for and add existing pages that matched the templates assigned to it from anywhere in the system (or a limited set). Basically, a PageTable/Page Field crossover.

Currently working on an update with bug fixes, translatable links, and (hopefully) ajax refresh when new pages are added. I should have something ready tomorrow. Edit: Made a lot of progress this weekend but will need a bit more time to iron things out. I was able to get the field to refresh when the Add New modal dialog is closed, which works great for single item selects and allows you to select the new item without refreshing the page. However, for asm-style multi-selects, the refresh wipes out your existing selection when it reloads. Because of this I think that another approach will be required.

Oh wow, that's perfect! So the Matrix field is basically an enhanced repeater with multiple templates? Similar to a PageTable except the fields are visible and editable inline and the setup is all automated? I think we are going to need to develop some sort of flow chart or documentation page specifically about the different types of repeating fields and why you would choose one over the other for a particular use case

Color me curious... The new Matrix field is huge!!! Is this using pages behind the scenes like a PageTable, or is it more like the table field?

I actually just tried this using the ProcessPageListMultipleSorting module. I set the sort for my parent template to -sort, and it showed the results in reverse like I wanted. New pages were added to the top. Of course, the problem is that the page tree doesn't realize that the sort is reversed, so when I try and move one of the pages, the whole order is recalculated based on the visible order, and thus it reverses the entire list. Anyway, I think it shows that this feature could be implemented without introducing extra overhead. It's just a matter of making the page tree javascript/php a bit 'smarter.'

Old thread, I know... But I had this issue again and was wondering if it would be possible to solve this problem by somehow reversing the visual display order in the page list rather than having to renumber the sort property of each page when a new page is created. So the new pages would still get higher sort numbers, but they would appear at the top?

@BernhardB - AJAX reload of the field sounds like a promising idea. I have not looked into how that works yet, but I will as soon as I get a chance! At this point I recommend only using the Add New feature if you're using the autocomplete field, since that doesn't require a page refresh to select the new item. I saw your unselect module and it looks great

I ended up taking a different approach entirely to my problem, so this wasn't an issue. But I believe the problem is that the redirect is trying to open in the modal window (it is just an iframe), but the window is being closed by PW's javascript before (or while) the redirect is happening. I think what you would need to do is change the target attribute of the iframe's form (using javascript) to _parent when the submit button is clicked. But I haven't fully thought through the implementation yet.

Awesome! You beat me to it

I am a fan of the php alternative syntax as well, szabesz, to keep the focus on the final HTML rather than on the logic when inside of a template and not have to escape your markup. And if you use short tags like <? if($foo): ?> and <?= $foo ?>, ternary statements like <?= $foo ? 'myclass' : '' ?> and leave off unnecessary semi-colons, then I find this solution cleaner and more readable most of the time. Like Ryan said, if you use php output buffering directly or separate all of your markup into individual files and load them using the TemplateFile class, then you can still use the delayed output method with alternative syntax. Personally, however, I prefer setting all templates (in the template settings in the admin) to point to a single output file and then handle the rest with php logic, loading subfiles based on the name of the current template. Actually, I've developed an entire (H)MVC framework on our latest project, which hopefully I will be mature enough to release some time soon. All that to say you can do anything with ProcessWire!

I did try $this->get() as well. I can try again. I'm glad to know that it should work, at least.

I'm trying out extending the Page class to add methods to pages of a particular template. I've discovered that when I try to use a magic method to access one of my fields from a method within the class (i.e. $this->title) it returns nothing. I am used to being able to call $event->object->title from within a hook, so I expected this to be even simpler when using a custom class. I can output $this->id okay, but not any of my custom fields. What am I missing here? Here is my code: <?php class PodcastEpisode extends Page { public function getFileUrl() { return $this->podcast_file ? $this->podcast_file->httpUrl : $this->podcast_file_url; } public function getFileSize() { return $this->podcast_file ? $this->podcast_file->filesize : $this->podcast_file_size; } public function getFileExt() { return $this->podcast_file ? $this->podcast_file->ext : pathinfo($this->podcast_file_url, PATHINFO_EXTENSION); } public function getFileType() { $fileType = ''; $fileTypes = array( 'audio/mpeg' => 'mp3', 'audio/x-m4a' => 'm4a', 'video/mp4' => 'mp4', 'video/x-m4v' => 'm4v', 'video/quicktime' => 'mov', 'application/pdf' => 'pdf', 'document/x-epub' => 'epub' ); foreach($fileTypes as $key => $value) { if(strcasecmp($value, $this->getfileExt()) == 0) { //If the value matches the file extension $fileType = $key; //Set $fileType to the corresponding File Type string from the $fileTypes array break; } } return $fileType; } }

I guess I should clarify. In this particular instance, my "module" is built for a particular website and it contains most of the hooks and custom logic for the entire site (the "model"). It also autoloads various custom classes that I have built for the site. I am using hooks in my module to effectively extend the functionality of the Page class for different templates. My controller code for each template is in the templates folder, however. So I presume that this is the reason why output formatting appears to be on "in the back end", because most of the time my hooks and functions are ultimately being called from a template file, which is loaded after PW has already switched on formatting. Does that sound right?

Yeah, that's what I was thinking. If you call a method from the module in the front end, then outputformatting would be on, so there's no way to really know for sure. That is exactly what's "so difficult about it." You have to be continually cognizant of what state you're in, which leaves a lot of places in the code where errors can creep in which may only show themselves under very specific scenarios. In other words, I can have a function that will work just fine during testing in one place, but when called from somewhere else will fail due to the state of output formatting on a particular page--which was modified by some other function in the meantime. That's not good. If I could, I would just use getUnformatted() all the time and call it a day. But even that won't solve the problem, since PW will still error if it happens that formatting is turned on for a page that I call save() on. I meant the entire code base for the website. I don't believe there is a short syntax for the $pages->setOutputFormatting(). I'll have to do some more testing and see what's causing this. Thanks for your help.

I have heard that said a few times, but it seems to be on by default everywhere for me. I wonder if there is a module I'm using that is turning it on? I just searched my project for "pages->setOutputFormatting" and "('pages')->setOutputFormatting" but only see two results: Once where it is being switched off in admin.php and once where it is switched on in ProcessPageView.module.