Robin S

Hi @tpr, I spotted an issue with the position of the InputfieldPageListSelect restore icon when the inputfield's width is not the last/only inputfield in a row: I fixed it with this: html.aos .InputfieldPageListSelect { position:relative; } .aos_pagelist_unselect.restore { right:0; transform:none; -webkit-transform:none; }

I think your issue is not due to any general problem with adding plugins for CKEditor, but due to the fact that images in PW must be stored in an image field. CKEditor is a third-party tool so by itself it doesn't have any idea about PW image fields. Theoretically a person could make a custom CKEditor plugin that could add images to a PW image field but to my knowledge no such plugin is available. So for now you will need to first add your images to an image field and then add them to CKEditor from there.

@cosmicsafari, as a general starting point you can get a clue of an API property name by looking at the input name in the PW admin using your browser dev tools.

I guess the SQL LIKE operators can recognise an escaped quote and treat it as such, whereas the other operators cannot. So that leaves you a bit stuck if you must use those other operators because you'll always have a potential clash of quote characters if you cannot escape quotes.

It would be nice if restoring a page could simultaneously restore relationships for that page, but I'd say the current behaviour is not unexpected. The same limitation would apply if the page had been selected in a Page Reference field (which is PageTable field is like an extended version of). If you check the names of pages in the Trash you can see how the location and sort position of the original page is stored: I guess it's just not practical to keep all the relationship information that applied to a page in this kind of format.

@thetuningspoon, the below seems to work well with any of the SQL LIKE operators. You could easily add it as a new $sanitizer method via hook if you wanted. Test title: Code: function prepSelectorValue($str) { return '"' . addslashes($str) . '"'; } $p = $pages(1107); // the page with the test title $title = prepSelectorValue($p->title); $items = $pages->find("title%=$title"); echo '<h2>Results</h2>'; echo $items->each("<p>{title}</p>"); Result:

Some hosts don't like 777 permissions - I suggest you change all directories to 755 and all files to 644 (apart from /site/config.php which should be more restricted). A good FTP client will be able to change permissions recursively, with separate permissions for directories and files. Another thing that could cause your issue is lack of disk space - check to make sure you haven't run out.

No, I'm not referring to the Alternate template file feature. I'm just saying that if you create a template without a file, and later decide you want to add a file for it, all you need to do is put that file (named the same as the template it relates to) into /site/templates/. Maybe you never tried it that way before but give it a go and you'll see what I mean.

Maybe I'm misunderstanding the situation here, but it isn't necessary to do anything in the PW admin or via the API to associate a template file with a template - you just add a file named the same as your template to /site/templates/. So if you created a template named "my_template" then you add a file "my_template.php". You don't have to create the template and the template file at the same time. You could create a template last week and add the file today and it is automatically associated with the template if the name is the same.

I'd be surprised if it worked with Profields Table as that is quite different from a normal Page Reference field. The relevant JS is here if you want to explore how it works. You could make a request for dependent selects in the Profields Table forum and see what Ryan says. It would be a nice feature. It works for me - see below (seems to work with "Custom find" too):

Regarding the filter options in the sidebar, I see a few approaches... 1. Foreach the search results This will not be efficient and personally I would rule it out. But the idea is that you iterate over all the pages in the search results PageArray and build up an array of unique categories that have been selected in the result pages, then you build your filter options from it. 2. Use the Connect Page Fields module Say you have the categories from the wireframe above (there are probably more but the principle is the same): Style, Frame, Surface. The child pages (the category options) use the templates "style_item", "frame_item", "surface_item". Your product template is called "product" and contains three Page Reference fields for selecting these categories named "style", "frame", "surface". You create a Page Reference field "selected_on" which allows the template "product" for selectable pages. You add this field to the templates "style_item", "frame_item", "surface_item". In the Connect Page Fields module config you make three connected field pairs: "style" <=> "selected_on", "frame" <=> "selected_on", "surface" <=> "selected_on". In your search results template you get the related categories with something like this: // find search results $results = $pages->find($your_selector); // get categories that have been selected in these results $related_categories = $pages->find("has_parent=/selects/product-categories/, template!=blank, selected_on=$results"); // build your filter from the related category pages... If you are limiting/paginating your result items (which you probably will be) you could use a separate $pages->findIDs() query to get just the IDs for use in the $related_categories selector. 3. Use SQL to query the tables of the category Page Reference fields You'd need a solid understanding of SQL for this approach. See this post for the general idea of how to query a field's table:

@Chris Falkenstein, if I understand right you are looking for the "dependent selects" feature. I covered what I know about it here:

The Paginator module is very nice solution. Another approach would be to add a "featured" checkbox to the article template. Then you use a Pages::saveReady() hook to keep the checkbox and the Page Reference field in sync - if an article is added to the Page Reference field you set the checkbox to 1 and vice versa. You could set the checkbox inputfield to hidden if you only want to use the Page Reference field to select featured articles. Then your articles selector would be "template=article, sort=featured,-post_date"

I'm not sure what's behind the issue you're seeing, but I tested basically the same code and it works for me. In the source page: <script> $(function() { var page_number = 12345; $.ajax({ type: "GET", data: {pnum: page_number}, dataType: "html", url: "/two/", success: function(data) { console.log('data: ' + data); } }); }); </script> And in the template for page "two": if($config->ajax) { $num = $input->get->pnum; echo "Num: $num"; return $this->halt(); } Logged to console: data: Num: 12345

Hi @teppo, I recently started using this great module. Tracy is picking up some error notices when opening a page containing a Repeater in Page Edit. PHP Notice: Trying to get property of non-object in ...\VersionControl\ProcessVersionControl.module:658 This seems to be due to the field names ($field) containing a "_repeater1234" suffix so wire('fields')->get($field) does not find a match and returns null.

I made a simple proof-of-concept module: ImageToMarkdown

A proof-of-concept module. ImageToMarkdown Alt+click an image in Page Edit to copy an image markdown string to clipboard. Usage Install the ImageToMarkdown module. Alt+click an image in Page Edit to copy an image markdown string to clipboard. If the "Description" field is populated it is used as the alt text. https://github.com/Toutouwai/ImageToMarkdown

I agree that you'd be better off with ordinary child pages than PageTable pages if there will be hundreds of them. Remember that you can access a paginated list of child pages from within Page Edit by visiting the Children tab, that you can long-click the "Edit" link to edit the child page in a modal, and that you can add extra fields to appear in the page list besides the title (and that can be further enhanced with AdminOnSteroids). So nearly as good a PageTable field.

Somehow I missed the enhanced icon select part of the module - damn, wish I found that earlier. I take you mean to propose changes for that in the core, because it isn't possible to do in a module.

@gebeer, I don't want to be pouring cold water on this but I have a feeling this approach is unlikely to work. At least not without giving the role edit access to the 'user' template, and it seems like that would be a security liability. But if you do get this working then cool. I suggest opening a GitHub request/issue to add proper support for FieldsetTab to ProcessProfile. Whether it's a request or an issue depends maybe on whether you think support for FieldsetTab was deliberately left out of ProcessProfile or was just an oversight. If you ask the responders in the other thread to "thumbs up" the issue on GitHub then hopefully Ryan will give it some attention soon. Until there is proper support in ProcessProfile you could consider if an accordion-style interface could be an okay substitute for a tabbed interface. You could change to closed Fieldsets instead of FieldsetTabs and then add a little JS so that only one Fieldset is open at a time (to keep the profile edit page from being overwhelming): $wire->addHookAfter('ProcessProfile::execute', function($event) { $out = $event->return; $js = " $(function() { $('.InputfieldFieldsetOpen label').click(function() { if($(this).parent().hasClass('InputfieldStateCollapsed')) { $('.InputfieldFieldsetOpen:not(.InputfieldStateCollapsed)').children('label').find('.toggle-icon').trigger('click'); } }); }); "; $out .= "<script>$js</script>"; $event->return = $out; }); You could stick with FieldsetTabs and adjust the JS to suit, but the open/close of the FieldsetTabs in ProcessProfile seems a little buggy to me (flickering, toggle icons in wrong state - not from the JS addition above, but untouched too).

But the idea is to filter the icons preview, not the select options.

Note: this functionality is now built into AdminOnSteroids. I'd hate to know how much accumulated time I have spent and how much eye-strain I have experienced over the last couple of years, hunting through the 675 icons in the "all icons" view for the one I want. Today I finally got around to doing something about it. IconsFilter Allows the "all icons" view in InputfieldIcon to be filtered by name. Usage Install the IconsFilter module. When viewing "all icons" in InputfieldIcon (Advanced tab of field/template settings) you can filter the icons by name using the filter input at top right. https://github.com/Toutouwai/IconsFilter @tpr, something that could be merged into AdminOnSteroids?

I'm not sure about this error, but just a correction to the code that is triggering it - line 204 in PW 2.8.35 is: $inputfield = $field->getInputfield($this->page); The legacy branch has been updated to 2.8.62 (despite what is says on the "Download" page) and the code in InputfieldRepeater.module has changed in this version. So you could try updating to 2.8.62 and see if that resolves the issue.

Yep, all went smoothly with an update from v1.0.0 beta - nice one

Yes, it was just a test of a first install. But just now I forked the module and added the new CroppableImage3.module to the module root (nothing else). With the current CI3 version already installed I installed the modified module via "Add Module From URL": https://github.com/Toutouwai/CroppableImage3/archive/master.zip This seemed to work without a hitch. Installing via the Upgrades module is perhaps a little different, but I have no way to test that.