Robin S

Each item in the paginator array is a separate selector for a $pages->find() operation - the results are concatenated together for pagination. So just include or exclude templates for any selector in the array like you would normally for $pages->find($selector). So for your example: $result = $paginator(array( "headline~=$q, template!=profile", "introtext~=$q, template!=profile", "body|whatever~=$q, template!=profile" ), $input->pageNum, 25);

@Jonathan Lahijani Really great post, thanks. Sounds like you put in quite a bit of work in this upgrade - is it okay to ask the approximate number of hours the project took?

@Juergen: At the cost of a couple of extra DB queries, you can use my new favourite tool Paginator: (thanks @LostKobrakai) include 'src/Paginator.php'; include 'src/PagesPaginator.php'; $paginator = new PagesPaginator(); $result = $paginator(array( "headline~=$q", "introtext~=$q", "body|whatever~=$q" ), $input->pageNum, 25);

You can use a hook to append a formatted created date to the end of the page list label. In /site/ready.php... $this->addHookAfter('ProcessPageListRender::getPageLabel', function($event) { $page = $event->arguments('page'); $created = date('d/m/y', $page->created); $event->return .= " $created"; });

The error in the logs could be a symptom rather than the cause of the problem. When it comes to out-of-the-blue errors like this the usual suspect for me is mod_security - it would be worth disabling this to see if it resolves the issue. You may be able to disable mod_security via cPanel or htaccess, but if you're not sure ask your host.

Yeah, I don't worry about that. No different to Repeater items in that respect. If you're concerned about orphaned pages you can set PageTable pages to be trashed or deleted if their parent page is deleted.

@Galo, I think the step you are missing is adding the plugin button to the CKEditor toolbar. The toolbar buttons are set in the field settings, on the Input tab. Edit: and you also need to activate the plugin for the field...

I'm not 100% clear on what you mean, but you could create a datetime field "sort_date" and use a save hook to copy the event date to it if one exists, otherwise copy the published date. Then sort by sort_date in your selector.

I'm not sure what you mean. It's just as @MadeMyDay explained - the order is stored as part of the field. You just need to get the "block" pages via the field rather than as children of a parent. Instead of... $blocks = $page->children('sort=sort'); ...do... $blocks = $page->my_pagetable_field;

The reason you are seeing pages from the trash is because you are using $pages->get() which returns a page regardless of access or status. Besides Adrian's suggestion you could use $pages->findOne() instead of $pages->get(). But I think the way you are adding a match to your $pages->find() result is going to cause a problem with your pagination - the additional match will appear on every page of results. The only way I can think of getting around this is to make the child page titles a property of the parent page so that parent page can be matched directly in your selector. Unfortunately there isn't a "has_child" feature similar to "has_parent". So perhaps make a page field in your event template and automatically add and remove child pages from it with hooks. Or use a PageTable or Repeater field for your event_date pages and only add event dates via this field.

I think the issue lies with the autoload condition: If this is changed to... 'autoload' => true, ...then it works for me. If you change this, do a refresh in Modules to clear the cache.

Check out the brilliant Paginator by @LostKobrakai: https://github.com/LostKobrakai/Paginator/ I mentioned Paginator in a post yesterday but I hadn't used it at that point. I've just tried it out and it works a treat for when you want to paginate the results of two or more $pages->find() operations. There aren't any detailed instructions yet but the example in the readme should be enough to go on. So for your case you want to avoid the foreach and instead create two separate selectors for use in Paginator. Something like: include 'src/Paginator.php'; include 'src/PagesPaginator.php'; $paginator = new PagesPaginator(); $result = $paginator(array( "template=property$selector, address~=$locality, sort=$sort_order", "template=property$selector, !address~=$locality, sort=$sort_order" ), $input->pageNum, 25);

Yes, but what is the problem with that? If it's a matter of not wanting the client name in the URL then these could be altered using Ryan's method from the CMS Critic case study.

One or more of these fields in your selector must be Page fields. If you are trying to match the title of the selected page(s) in your search then use a subfield selector for the page title. For example, instead of... $selector = "my_page_field~=$q"; ...do... $selector = "my_page_field.title~=$q"; I suspect that otherwise PW thinks that you might be trying to match the page ID to the number in your search query, which doesn't allow a ~= operator.

Did you look into the module mr-fan suggested earlier? This sounds like it would be ideal for what you want to do. Any reason it's not suitable?

I can see two options: 1. Use Javascript to write something that identifies the article into a field in your form when a checkbox is checked. I can see this getting fiddly when it comes to dealing with multiple selected articles and removing articles from the field if their checkbox is later unchecked. 2. Place the articles inside the form, so checked articles are included with the form submission. Then when you process the form you look for checked articles. PS. I recommend you use something without spaces for your input name, e.g. $article->name

Just wondering why you would need to do this. A PageTable field does not necessarily include all the children of a given parent so the contents/order of the field could never match the children in all circumstances. I would have thought that if you create a PageTable field then you interact with its pages via the field (whether we're talking about the API or the admin interface) rather than the page tree. Personally, I always store my PageTable pages under the admin branch so they're not visible/confusing for clients.

Sounds like you have identified the likely source of the problem. Can you explain exactly what the setup is with these two instances of PW and the reason for it? Are you following one of the options described in the multiple-site documentation? If these are two entirely separate installations of PW that both relate to the same client then I would be inclined to place each instance in it's own dedicated hosting account. Then use a subdomain of the client's domain to point to the second hosting account.

http://php.net/manual/en/language.types.string.php#language.types.string.syntax.heredoc

The bit that I can't work out at the moment is how to set the matrix item type using a friendly name. I'm sure @ryan will have built in a way to do this, but until he responds you can set the matrix type as an integer using "repeater_matrix_type". First you need to find out the integer for the type of row you want to add. You can do this by dumping a repeater item of the right type and checking the repeater_matrix_type value in Tracy. Or you can open the field settings and inspect the source for the type you want to add. For example, in the screenshot below you can see the id of the inputfield for the "body" type is "matrix3_item", therefore the repeater_matrix_type integer is 3. So find out the repeater_matrix_type value (integer) for "article_content_text" and then you would run some code like this... $articles = $pages->find("template=article"); foreach($articles as $article) { $text = $article->article_text; $article->of(false); $new_item = $article->my_matrix_field->getNew(); // replace with the name of your matrix field $new_item->repeater_matrix_type = 3; // replace with the integer of your matrix type $new_item->article_text = $text; // assuming you added the article_text field to this matrix type $new_item->save(); $article->my_matrix_field->add($new_item); $article->save(); } But first test this works for a single article page before you process all the articles.

Sadly I don't think it's possible to sort by whether some condition is true, e.g. sort=[props.name=featured] I think switching to separate checkboxes for each property you may want to sort on would be the easiest solution. If you want to stick with the Page field and the number of featured articles is likely to always be less than $limit then you could do something like... $featured = $page->children("props=featured, images.count>0, sort=$sort"); // no sub-selector for props is necessary $articles = $page->children("images.count>0, sort=$sort, limit=$limit")->filter("id!=$featured"); Then on page 1 of the results you loop over $featured, followed by $articles. Alternatively I think Paginator by @LostKobrakai is designed for this kind of scenario but I'm not sure how it works. Maybe he will reply with some tips.

I think this is the "Use Compiled File?" section on the Files tab:

The Repeater Matrix documentation seems to be lacking in this regard - I have requested some in the Repeater Matrix subforum.

Can a user theoretically sign up for a project but not sign up for any phases or events? If not then I suggest that the user only signs up for events, and this implicitly also attaches them to phases and projects by virtue of the page hierarchy above event pages. Users are pages, so each event has a Page field that stores all the users that have signed up for that event.

The CSV format is so simple you can easily create a template to generate the right output. As an example: <?php header('Content-Type: text/csv'); header('Content-Disposition: attachment; filename="export.csv"'); $items = $pages->find("template=basic_page"); echo "title,url" . PHP_EOL; foreach($items as $item) { echo "\"$item->title\",\"$item->url\"" . PHP_EOL; }