ryan

Caches and modal popups can be a challenge sometimes. You may need to right click in the window and (in FF) choose: frame > reload.

Can you describe more how to duplicate? I might be doing it incorrectly, because I can't duplicate yet. Tell me what I'm missing (I'm using Chrome): 1. Click image icon in TinyMCE, select image (my example is 900 px wide). 2. Enter 200 for width, hit enter, and click "insert image" and image appears in editor. 3. Back in TinyMCE, click image to highlight, and click image icon again. Following that, my image is still 200x150. What am I missing? Also, right click somewhere in the image edit window, and choose "Reload Frame". That will make Chrome reload the CSS and JS files, just in case it has an older version cached.

Sounds intriguing–I'm very interested in hearing more about this.

@Pete–this has been added in the latest commit.

@Soma, oddly enough this issue just started happening to me on my desktop computer with the latest Chrome. Though it didn't matter what width I had the window at, the image would just disappear whenever I selected one and I basically got the same thing as you. As far as I can tell, it's a bug in Chrome. But I found an easy fix, and that was just to add a height attribute to the image. That seems to fix it here. When you have a moment, would you mind giving it a try over there? While I was there, I added width/height pixel inputs for specifying image dimensions. I think Pete had asked for this awhile back, I need to track down that thread.

Great suggestions from Soma, thanks! For these types of features, I recommend you build your own forms on the front end, and use the PW API to populate the pages. PW's admin is meant for administrators, not regular site users updating profiles. When you build your own forms on the front end, access control becomes quite simple. You can just give them a textarea field to edit and then keep some other field on the page that keeps track of what user is allowed to edit. That field could be a page reference to the users list, or it could even just be a text field with their username (whatever you prefer). Or, you could just repurpose the page's built-in 'name' field for this. If their username matches the page's name, they can edit. For example: <?php if($user->name == "user-" . $page->name) { // user can edit the 'about_me' field on this page if($input->post->submit) { // user is submitting a change $page->setOutputFormatting(false); $page->about_me = $sanitizer->textarea($input->post->about_me); $page->save(); $page->setOutputFormatting(true); echo "<h2>Your change has been saved.</h2>"; } else { // give user a form to edit echo "<h2>About " . ucfirst($user->name) . "</h2>"; echo "<form action='./' method='post'>"; echo "<textarea name='about_me'>{$page->about_me}</textarea>"; echo "<input type='submit' name='submit' />"; echo "</form>"; } }

I agree, that makes sense. I'll work on this.

AdminBar is great! But you already knew that. Thanks for the update.

I think the problem is this line: $cover=$item->LargeImage->URL; For instance, try this, and I'm guessing it'll tell you it's an object: var_dump($item->LargeImage->URL); When accessing elements like this, SimpleXML returns objects, not strings. You have to typecast it to a string, like this: $cover = (string) $item->LargeImage->URL; Many of the other elements you are pulling are already being typecast as strings by way of str_replace, preg_replace, strtolower, $sanitizer->text(), etc., so that's good. But you'll want to typecast these ones as strings too: $publisher=$item->ItemAttributes->Publisher; $isbn13=$item->ItemAttributes->EAN; $isbn10=$item->ItemAttributes->ISBN; $cover=$item->LargeImage->URL; This is one of those things about PHP's SimpleXML that has stung me more than once.

This is where that error is coming from, in /wire/modules/Process/ProcessPageEditImageSelect.module: if(!$this->page->viewable()) throw new WireException("You do not have access to images on this page"); The question is why does it think the page you are trying to pull images from is not viewable. Just a guess here, but: Does the page lack a template file (on the file system?). Pages without a template file are considered not viewable() by anyone. So trying to pull images from a page without a template file would produce the error you got. Looking at this now, I'm thinking I should find another way to check access here.

Got your PM– The encoding on that page is ISO-8859-1. Likely that's the default on your server in Apache, and since you aren't overriding it, it's taking control. You need to add this right after your opening <head> tag in your site's main/header template: <meta http-equiv="content-type" content="text/html; charset=utf-8" />

So far I can't duplicate this. Though a search in Google reveals that others have seen this with TinyMCE (in other CMSs), though not an obvious answer. Can you forward a URL to me that has these characters showing up in it? Post in here, or PM it to me if confidential. I want to have a look at what headers the server sends before the page get rendered.

Thanks for letting us know what it was. Glad you got it all working.

The problem is right here: <?=$user->name?> That's a PHP short tag. The majority of PHP installations have them enabled, but not all do. As a result, it's not always safe to use short tags in things like admin themes, modules, or templates/profiles intended for broad distribution. @almonk: next time you are making updates, this can be fixed just by changing it to: <?php echo $user->name; ?>

Thanks guys. The main thing I want to add is the ability to select which pages should have their cache cleared by way of what template they are using (i.e. clear all pages using template 'basic-page'). But that's a little more complex, so holding off until it comes up again.

Soma's suggestion is correct–thanks Soma! Another way to do the same thing: if($session->authenticate($user, $old_pass)) { $user->pass = $new_pass; }

Glad you found the source of it. Let me know if you want any help in determining why the module was interfering.

I'm thinking that would only work if your related_pages field was set with this (in the details tab when editing your related_pages field): So it confuses me that your example was cycling multiple pages when it would appear that you have a single page field set to return false when empty. Either that, or PHP uses the Countable interface in typecasting to boolean comparisons (can't say as though I've tried). In either case, you may want to choose this instead, if haven't already: And code it like this: <?php if(count($page->related_pages)) { echo "<h2>Related pages:</h2><ul>"; foreach($page->related_pages as $related_page) { echo "<li>{$related_page->title}</li>"; } echo "</ul>"; }

All image fields are technically multi-image fields. The single-image access (when a field is set to 1 image max) is a type of outputFormatting for convenience on the front-end. All pages on the front-end of your site have outputFormatting turned on by default. When outputFormatting is on, it means the page is in a presentation-mode as opposed to a saveable mode. In presentation (outputFormatting) mode, pages are setup for presentation convenience and safety. The distinction exists so that content can be modified at runtime with custom formatters and such, without worry of that runtime-info ending up saved back into the database. This is why ProcessWire throws an error if you try to save a page with outputFormatting on. outputFormatting is also what converts an images field with a 1-image max to a single image rather than an array of 1 image. That's because I thought people would find it confusing on the front end to have to use an array when all they are dealing with is 1 image. Whereas, when coding for administration of any image(s) field, it's more convenient to treat them all the same way. When you are in the admin, pages don't come with outputFormatting on by default. Since it sounds like you are presenting content in the admin kind of like how you would on the front end, you can either turn on outputFormatting for those pages you are presenting content from, or better yet: treat all image fields as multi-image fields. If you do that, just remember that all text-based content is in a raw state. For instance, if you want to output an <img> tag with an alt attribute: <?php foreach($page->images as $img) { $alt = htmlentities($img->description, ENT_QUOTES, "UTF-8"); echo "<img src='{$img->url}' alt='$alt' /> } When building admin stuff, it's generally actually always better to have outputFormatting off.

What is the encoding of the document you are copying the text from? After pasting in the text, do you see these characters in TinyMCE (PW admin) or just on your website? If you see them in TinyMCE, do you only see them after saving the page, or do you see them immediately after pasting the text into the document? Based on your answers to the above, I think we'll be able to figure it out. Also, just to double check, look in your browser what character set it's using. In Chrome, it would be View > Encoding. In Firefox, View > Character Encoding. It should say "UTF-8"–let me know if it doesn't.

I've been meaning to upgrade the caching options in the templates editor. It's easy to do, so I went ahead and put it in place and it's now committed to the source. Now you can choose any of these cache clearing options: When page is saved: Clear the page's cache (default) Clear the entire site's cache Clear the page's cache and it's parents (including homepage) Clear specific pages (with page list selection) Don't clear anything Attached is a screenshot with the #4 option selected. In ProcessWire, using the cache is definitely not required. I leave it off for smaller or lower traffic sites, and then use it only on some templates with higher traffic sites. But now that there are more clearing options, I may start using it a lot more. But my goal is always to keep ProcessWire fast whether you have the cache turned on or not. But there's no doubt that caching can make a big difference on pages where you are performing heavy operations.

I've added $user->addRole() and $user->removeRole() methods and confirmed everything is consistent with the docs page. Thanks for finding this. I also added $role->addPermission() and $role->removePermission() just to enable consistent syntax between User and Role types.

Thanks for the screenshots. So that's good to know that the code snippet works for the first image–what happens if you replace it with this? <?php foreach($page->assets as $inc) { if(count($inc->fileimages)) foreach($inc->fileimages as $f) echo $f->basename . '<br />'; } If it fails, check your field settings for 'fileimages' and and 'assets', and uncheck any boxes for 'autojoin'.

Pete, can't duplicate here either. You might want to check with Acronis to see if she is experimenting with your templates. ;D

While it sounds good, it's actually a bit complicated because it would mean that all Inputfields that can be used for selecting pages would have to check the Page's status and include some additional markup related to it. ProcessWire lets you use any multiple-selection Inputfield for selecting pages, and the vast majority don't know what a Page is. They just know how to provide multiple selection. That means they are quite flexible and can be used in the API for any collection of items. But if I start building Page dependencies into Inputfields, then they suddenly become limited to Page selection. I'd rather keep them flexible... I need to keep PW's size reasonable at least until there is a bigger team behind it. But the scenario that you point out is a good one. I am thinking the best way to handle it is for PW to include the unpublished pages in the 'selected' list if it detects that you are actually editing the page. This won't work with all Inputfields (which require the selected to be part of the selectable), but it will work with the PageListSelectMultiple that was shown in the YouTube video… and that Inputfield is the only one that can call out unpublished pages anyway.