Robin S

Good solution, thanks! Just curious: what is it about the /processwire/ branch that makes it hidden to non-superusers? Is it possible to create new branches that are hidden like this?

I'm using a PageTable field for the first time. I've set up the field so pages used in the PageTable field are stored under a separate "Tools" page. I want site editors to be able to view and edit PageTable pages via the PageTable field, but not see those pages in the page tree. Is that possible?

I think your problem comes from this: $root = $page->parents->count == 1 ? $page : $page->parent; For the first two levels $root is "Products", but on the third level $root is "product 2" or whatever level 2 parent you are in. So you only see children of "product 2". I think this will do what you want: $root = $page->rootParent;

I'm experiencing the same issue. If the repeater item is opened individually in Edit Page (via Find) then the image is editable but it is not editable in the context of the page containing the repeater field. Is this the expected behaviour for image fields in repeaters? Also, I notice that images in repeaters have a green header rather than the normal blue header. What is the significance of the green header?

Update: I think the problem is more general. When using more than one text formatter (can be any text formatters) on a files or images field, only the first text formatter is applied. Can anyone confirm? Edit: filed issue at Github.

I'm using the core "Markdown/Parsedown Extra" and "Paragraph Stripper" text formatters on the descriptions of an image field, via the field setup in admin. The paragraph stripper needs to come after the markdown formatter, but it seems the order the text formatters are applied is the opposite of what it should be. Edit: Sorry, my description of the problem was wrong there. But it seems there is some incompatibility with "Markdown/Parsedown Extra" and "Paragraph Stripper" when used together on image descriptions. If markdown is first and the paragraph stripper second then the paragraphs are not stripped. If paragraph stripper is first and markdown second (i.e. the wrong order) then the markdown formatter isn't applied at all. But the two text formatters seem to work correctly together for text fields. Please see update below

Ryan, that selector would fail to match a page where text_field is "my cat and my dog" and page_field is "5555" (or empty). It's taken me a little while to get my head around the way OR-groups work, but my current understanding is that if you need an AND relationship between OR-groups (as I do in my example) then the OR-groups need to be named. Otherwise the effect is (or-group) OR (or-group) OR (or-group)...etc.

That selector doesn't give quite the right results. There's no AND component to it, so it would match any page that has cat OR dog OR 1234 OR 4321. I think the selector in my third post... $pages->find("foo=(text_field*=cat), foo=(page_field=1234), bar=(text_field*=dog), bar=(page_field=4321)"); ...might be as succinct as it gets. And nothing wrong with it, I just thought there might be something simpler I was overlooking. It's also totally possible to use the $items->add approach you suggested initially, just a bit more involved to deal with the pagination. Found a great post from Soma that spells it out.

Thanks. I considered the $items->add approach but it makes sorting and pagination more difficult than with a single find operation.

$pages->find("foo=(text_field*=cat), foo=(page_field=1234), bar=(text_field*=dog), bar=(page_field=4321)"); Is that right? Anything more succinct that that possible?

Problem solved - I just needed to give a name to the OR-group: $pages->find("foo=(text_field*=cat, page_field=1234), foo=(text_field*=dog, page_field=4321)"); Nope, that's not right. I'm going to kick myself when I get this...

I'm sure there's a simple answer to this that's staring me in the face but I'm struggling to work out the right combination of pipe separators and OR-groups. How do I write a selector for the following: (text_field*=cat OR page_field=1234) AND (text_field*=dog OR page_field=4321)

Thanks, that does the trick.

I have several Page fields in my template, some are "multiple page" fields and some are "single page" fields. When looping through my template fields I need to also foreach the multiple page fields. What is a good way to test for multiple vs single page fields? Or if I know I want to loop through my Page fields is it better to set them all to dereference as PageArrays?

Another option to consider is ProFields Table. For many things it's a good alternative to repeaters and the UI is a lot more compact.

Form Builder has this functionality. Form submissions can be displayed in a table in the PW admin or saved as pages.

Thanks! I was hoping there was some sort of find method for page fields, and of the two options I'll probably use this. But for $myFields->add($f); ...if I know the name of the field I want to add to the FieldsArray, how do I get the item into the right type for adding to a FieldsArray? Edit: worked it out now... $myFields = new FieldsArray(); $myFields->add($page->fields->get("fieldname"));

Using $page->fields makes it easy to output field labels and values for a page in a foreach loop, which is great when you have fields that you want to output with the same markup structure. But what if I don't want all the fields in the page, but just some of the fields, so I can use two or three different foreach loops for different markup needs. The docs say that $page->fields returns a "FieldsArray". How can I create my own FieldsArray, selecting fields by name? Or maybe filter $page->fields by field name?

Thanks, yes, those were my thoughts also a couple of posts up. Seems to work well with UTF-8 characters instead of HTML entities. There's no need to entity encode the characters inserted by SmartyPants for modern websites using charset UTF-8. I think this should be the default for TextformatterSmartypants, or at least an option, if this makes the module compatible with TextformatterEntities - using them together is pretty important for anyone who wants both valid HTML and correct punctuation from plain text fields. I'll try my hand at modifying TextformatterSmartypants to give the option of UTF-8 or HTML entities and submit a pull request.

Ah, I get you now, and it works. Though it does seem like using the Markdown parser on text that does not intentionally contain Markdown is risky - could create as many problems as it solves. I can imagine situations where an editor enters a plus, minus or asterisk at the start of a line and a list item inadvertently results. I guess I could always add a strip tags textformatter at the end to remove any HTML tags added by the markdown textformatter, but that is getting kinda crazy.

Thanks, but I'm not clear on what you're getting at. My first post explains that using the textformatters in either order gives unsatisfactory results. I believe the problem is that SmartyPants encodes the quote mark, dash and ellipsis punctuation as HTML entities (but no other characters, so it can't be used as a replacement for HTML Entity Encoder unfortunately), and then HTML Entity Encoder double-encodes the ampersand character in those entities. Two possible solutions I can see: Modify HTML Entity Encoder to allow the "double_encode" parameter to be used in htmlspecialchars, which avoids the double-encoding of existing HTML entities. The downside is that it wouldn't be possible to have literal text like "&" appear in the output. Funnily enough, this problem manifests in the PW wiki article you linked to, with phrases like Modify SmartyPants so that it inserts UTF-8 characters rather than HTML entities. I tried this and it seems to be a good solution. If there are no major downsides to this maybe Ryan will consider adapting the core TextformatterSmartyPants module to allow this as an option.

I can understand that, but in the case of SmartyPants and HTML Entity Encoder these are both essential formatters in my book. SmartyPants for proper quote mark typography and HTML Entity Encoder for valid HTML from plain text fields. I'm surprised they don't work together, which makes me think I must be missing something.

Are the SmartyPants and HTML Entity Encoder textformatters compatible with each other? If I apply Entity Encoder first and SmartyPants second then the quotes stay "dumb". If I apply SmartyPants first and Entity Encoder second then I get code like ’ in my field output.

I reset the database password for site2 (I don't think it was wrong but just starting the process of double-checking things) and now I'm able to access site2 without problem. Weird, not sure why a db password problem would cause a 500 Internal Server Error. But all working now so happy joy

I'm having trouble getting a multi-site installation (I'll call them "site1" and "site2") working on a shared cPanel host. The installation was working on my local hosting environment with two virtualhosts pointed at the same folder, allowing me to access both sites. On the cPanel server I'm wanting to use subdomains for both sites: site1.mydomain.com and site2.mydomain.com So in my cPanel hosting I have site1.mydomain.com as the primary domain for the account, and I have added site2.mydomain.com as a cPanel domain Alias (I believe this was called a "Parked Domain" in previous versions of cPanel). Before I edit index.config.php to perform the redirect to site2 I am able to see site1 at both site1.mydomain.com and site2.mydomain.com. But after I edit index.config.php to redirect I get: Maybe someone has experience with setting up a multi-site installation on cPanel. Is adding the domain for site2 as an alias/parked domain the right move? Something else I need to configure in cPanel?