ryan
-
Posts
17,307 -
Joined
-
Days Won
1,725
Everything posted by ryan
-
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.
-
The FieldtypePage won't present unpublished page references in it's output. That Inputfield that you are using there will show all pages that you have access to. The strikethrough on it means that it's unpublished and not ready to be used for presentation, links, references, etc. It'll let you select it (unlike other Inputfields), and actually it does get stored. But when it comes time to load it again, it gets filtered out. It does it like this at load rather than save because a page that was published could now be unpublished, and likewise a page added in the API that was unpublished could now be published. Perhaps it shouldn't show unpublished pages in that PageList, but I figured the strikethrough here was clear enough and didn't want to add to the code complexity of the PageList process (which doesn't even know it's been used as an Inputfield).
-
Check your settings for the 'fileimages' field. What is the "max number of files" set at? If it's set at "1", then you should be able to access the field like in your example. If not, then you should set it to 1 in order to make your example work. To ProcessWire, all file/image fields are multi-file fields (Pagefiles). But as a convenience, it converts them to a single file field (Pagefile) if you specify that the field will only allow a max of 1 file. So if I'm correct, you either need to set it to 1, or treat it as a multi-file field, like this: echo $inc->fileimages->first()->basename; or foreach($inc->fileimages as $file) { echo $file->basename; } Let me know if I'm incorrect about this. It has come up a couple of times, so I'm thinking about adding some more clarification/configuration options in the field settings.
-
This topic has been moved to Themes and Profiles. [iurl]http://processwire.com/talk/index.php?topic=162.0[/iurl]
-
This topic has been moved to Themes and Profiles. [iurl]http://processwire.com/talk/index.php?topic=186.0[/iurl] -
This topic has been moved to Themes and Profiles. [iurl]http://processwire.com/talk/index.php?topic=252.0[/iurl]
