Robin S

It would be possible to get the relationship at the time a page is trashed - for instance, with a PageTable field you could hook InputfieldPageTable::processInput() and get the pages about to be trashed. As for simple it depends on what you're comfortable with. To store the information in a self-contained way your module would need to create and use its own database table. There are existing modules you could look at as an example of how to do this, e.g. Template Access by Parents

Right you are. When you open a request there is a dropdown to select which Pro module you are wanting help with. So all good I guess. Just funny that there's no mention of this section in the Pro modules information, rather the private sub-forums are mentioned as where support is provided. I have a number of Pro modules and I don't recall ever hearing about it. So probably LK is right and it just comes as part of the store package.

By "Support" section I mean this: I've never even looked in this section before, and I haven't heard of anyone using it. But based on a comment today maybe some new users do go there looking for help: Is this section used by the community and monitored by anyone? If not perhaps it should be removed. Thoughts?

@tpr, just a heads up about another issue over on GitHub along with a possible fix.

@tpr, I've been having a look at the images-in-repeater issue for non-superusers (I discovered this one a while back but forgot to report it here, sorry ). ----- Edit: I did report it over in the Github repo. Edit 2: looking at some PM history it looks like a solution (same intent but different implementation to that proposed below) was found but never merged into the repo? ----- As you found, the $this->editedPage property is the source of the issue. Seeing as the things this property is used for within the module either don't work within repeaters (e.g. field edit links) or aren't needed for repeater pages (e.g. breadcrumb features) I think $this->editedPage should never be set to a repeater page. But it's much easier to exclude repeater pages in ready() because in init() it is not yet known which class a page is an instance of. So could $this->editedPage be set in ready() instead? This is what I did in my testing and it seems to work okay: public function init() { // removed code that sets $this->edited page // populate self::$configData self::$configData = $this->modules->getModuleConfigData($this); // ... // a bit further down we need to change $configData[$subModule] to self::$configData[$subModule] public function ready() { // set $this->editedPage // excluded repeater pages, minor refactoring $this->editedPage = false; $editedPageId = $this->sanitizer->int($this->config->input->get->id); $editedPage = $this->pages->get($editedPageId); if( $editedPage->id && !($editedPage instanceof RepeaterPage) ) $this->editedPage = $editedPage; self::$configData = $this->modifyConfigData( $this->modules->getModuleConfigData($this), $this->editedPage ); // ...

I think you want: if($config->ajax) {} $config->ajax

Works great, thanks!

I can confirm that sorting by repeater count does not work. Seems like a bug to me, considering that it's possible to sort by Page Reference count and PageTable count and those are quite similar fieldtypes. @Tom., maybe open an issue on GitHub?

In another thread Ryan said: Might be something in the discussion that helps:

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