ryan
-
Posts
17,242 -
Joined
-
Days Won
1,704
Everything posted by ryan
-
@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.
- 1 reply
-
- 1
-
-
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.
-
Nice job! Tried it out and seems to work great. I've just updated the Admin Themes page with your theme and Soma's: http://processwire.com/download/admin-themes/
-
What version of ProcessWire are you using? When you edit the page, do you see files/images on it? Can you confirm that the field is called 'fileimages' (lowercase) in your Setup > Fields? Do the pages in $page->assets have any page references of their own? On the surface at least, it sounds like there are no images on one of the $inc pages. I would expect this error if that were the case. Before accessing a file/image, you need to check that it's populated: <?php // single file field (max images=1) if($inc->fileimages) echo $inc->fileimages->basename; // multi file field (max images=0 or > 1) if(count($inc->fileimages)) echo $inc->fileimages->first()->basename; Not sure if that's the case here, but wanted to mention it just in case. It's always a good idea to check that a file field is populated before outputting it. Thanks, Ryan
-
Technically all API access is superuser, since the API doesn't pay any attention to the user. But there is one exception: any function that returns a PageArray will filter out results that the current user doesn't have access to. That's done as a convenience so that you don't have to check access for every page that gets returned from a find() operation. It's also necessary for things like pagination to function with low overhead. These options are provided so that you can change that behavior for any given find operation: <?php $pages->find("[selector], include=all"); // include ALL results, with no access or status filtering $pages->find("[selector], include=hidden"); // allow inclusion of results that have 'hidden' status $pages->find("[selector], check_access=0"); // don't check access (roles) when finding results However, when calling find() from $users->find(), $roles->find() or $permissions->find(), it's supposed to automatically add the "include=all" for you, and it wasn't. So that was bug that was limiting access too much. I've just fixed it in the latest commit, thanks for finding it. As for making the bootstrap API assume the user is superuser for $pages->find() operations, I'm reluctant to do that just because I think whether that's desirable or not really depends on the context. If I was bootstrapping the API for use in some other application, I would still want PW to honor my permission settings in $pages->find() operations the majority of the time. But for the times you don't, add the "include=all" to your selector, or change the user to be who you want: <?php $users = wire('users'); $superuser = $users->get("apeisa"); $users->setCurrentUser($superuser);
-
This is for the User class right? I only ask because I see a commented addRole() in the Page class, but not in the User class. Though the context here seems to be Users, since roles are on templates not pages. So I'm thinking we're talking about the User class, but let me know if I'm wrong. There are some updates that I need to make to the API docs throughout (though additions, not removals). I'm not remembering why I removed the addRole/removeRole from the User class, but I will add them back. It's not commented in my source. Can you paste in the commented function you are talking about? I'm just confused about why you've got it and I don't, so I want to make sure I'm not missing anything important. Btw, here's how to accomplish the same thing, though not as pretty as $user->addRole('rolename'); $user->roles->add($roles->get("rolename")); Titles are optional for roles already (you have the option to add it to the role template). But once you add a title field to the template, it's no longer optional. I figure that separate name and title are redundant until you have complex needs, which is why it's not there already. So I left it as something that you can add to your role template if you want it. When creating any kind of page reference, it lets you choose what you want to be the 'label' field. It will show you all the fields in the system, with 'title' being the first (default) as it's the obvious choice in most cases. But with a Role, unless you add a title field, you'd want to change it to use 'name' as the label field. Role and user are the only templates in PW that have no title by default.
