Robin S

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?

Thanks, seems like a good approach. Was unsure at first whether the "id" value in the JSON export needed to be incremented when duplicating for import, but after testing it looks like PW ignores the id value on import and assigns a new id, so no need to worry about that.

I have an idea for an enhancement: for the "Enable + New link?" option it would be great if the newly added page was automatically selected in the Page field. Ideally it would show as selected immediately after closing the modal window (reload the Page field via AJAX?), or otherwise show as selected after saving/refreshing Page Edit. If a person is adding a new page from within Page Edit I think it's likely they want to select that option also. I also noticed a quirk in that the "+ New" link is not rendered unless the "Enable view/edit link(s)?" option is also selected.

This is in the core now for PW dev, so no module needed. However, the "Enable + New link?" feature of this module is nearly what I was hoping for. It allows the addition of new pages in a modal window. The only catch is that the added page is not available for selection until the page being edited is saved or reloaded. Thanks for pointing me in the right direction.

The "Allow new pages to be created from field?" option is great for site editors, but you can really only allow this if the template used in your Page field only needs the Title filled out. If your template requires other fields then editors need to leave the page they are editing and create a new page from the tree or from "Add New". It would be cool if there was an option to add new pages to the Page field via a modal window (like the one you get if you allow edit links for the field).

@adrian: I'd love to try your modified Batcher module for adding multiple fields - nice to have a GUI for the task. I've seen other modified Batcher modules posted on the forum so I figure Wanze is okay with this. Maybe you could post the module here or fork it on Github?

Great idea! If I understand correctly, the module looks for a glossary page with a title that matches the text between the pipe delimiters. I'm wondering about cases where the term in the textarea needs to be slightly different than the glossary page title, for instance if you need to use a plural form of term. Say I have a glossary page for "mouse" but in my textarea I need to say "mice" - could a variation like that still be linked to the glossary item? Perhaps introduce some syntax to manually specify the glossary term for such cases?

The "toggle all" checkbox doesn't seem to be working. I had a play around with the JS and changing $('input.toggle_all').click(function()... to $(document).on('click', 'input.toggle_all', function()... seemed to do the trick.

That is brilliant - thanks!

Incidentally, when I set out to achieve a blurred image effect I initially thought I would do it client-side. Each client-side option I tried had issues: CSS filter - not supported in IE SVG filter - blur effect noticeably less smooth JS stackblur plugins - difficult to use as a CSS background image supporting background position and background size properties In the end it was so much easier to do it server-side, and browser support is 100%. Edit: for those interested in client-side image manipulation, CamanJS is pretty cool. It's an absolute breeze to use on inline images using the "data-caman" attribute, just a bit of a hassle to use it for CSS backgrounds.

Not really sure what you're getting at here. Do you mean you could do this in Photoshop? Because you could, but Photoshop doesn't run on your server. This is for processing images on a website, maintainable by your client. You're going to download, open Photoshop, filter and reupload each time your client changes an image? That's definitely not more efficient.

Not a module, just a little function for applying effects to images if you have the Imagick PHP extension installed. This started out as a need to blur an image and then I expanded it to accept more of the Imagick methods. Not all Imagick methods are supported. The function takes the URL to a source image, the name of an Imagick method and an array of arguments for that method, and returns the URL to the processed image. The processed image is saved to same directory as the source image, with the method name and arguments appended to the name of the source image. Images are cached in that the function checks if an image with that name/method/arguments exists already to save recreating it on every page load. function imagickal($imagePath, $method, array $arguments) { $path_parts = pathinfo($imagePath); $dirname = $path_parts['dirname'] . '/'; $filename = $path_parts['filename']; $mod = $method . '-' . implode($arguments, '-'); $mod = wire('sanitizer')->filename($mod, true); $savename = $dirname . $filename . '_' . $mod . '.jpg'; if (!file_exists($_SERVER['DOCUMENT_ROOT'] . $savename)) { $image = new Imagick($_SERVER['DOCUMENT_ROOT'] . $imagePath); call_user_func_array([$image, $method], $arguments); $image->writeImage($_SERVER['DOCUMENT_ROOT'] . $savename); } return $savename; } I'm a PHP novice so happy to receive suggestions of how this could be improved. Imagick reference: http://php.net/manual/en/class.imagick.php Examples of some effects possibilities...

I've just watched the demo video for the amazing Visual Page Selector module that kongondo is working on and it's got me thinking about the one-image-per-page approach to managing images. I haven't had a project that needed to reuse images on a large scale but I can see how it would be a good approach for managing a media library. My question: when it comes to adding new images in the one-image-per-page approach, I understand how it's easy to do this via the API but how do you make it easy for site editors to add multiple images at once and add descriptions and tags to those images? Has anyone devised a module that that allows images to be added and described from within the PW admin? Or would it be simpler to create a form on the frontend (with restricted access) to handle image uploads/descriptions/tags?

Ahh, it's a Firefox-specific issue. Thanks for the info. There are probably ways to get the desired behaviour in Firefox (e.g. give the password and confirm fields similar properties so they both get autofilled, or load the Set Password field with AJAX only if it is opened), but maybe it's not considered worthwhile to make such changes just for the quirks of one browser.

I think this has been requested before, but I can't find the thread I read it in. The user profile page can contain the selection for admin theme if more than one is installed, and possibly other fields too I believe. It would be good if these fields could be changed without having having to enter the user password. Also, if you forget to type in the password when attempting to change another field on this page and get the "Passwords do not match" error the change you were trying to make is not remembered and you have to make the change again.

Github issue is here for those interested, along with a suggestion for an alternative approach to making the input form pretty.

Setting the CKEditor field to inline mode does fix the bug. I think I have traced the bug back to these lines of JS code, which attempts to match the height of adjacent columns with every change (e.g. keypress) to the CKEditor field. Will open a Github issue for this.