Search the Community

It really depends what cache you are talking about? Template cache, Markup cache, runtime memory cache, ProCache? All of these caches usually clear themselves for the saved page, so you don't usually have to consider the cache except for pages that may be pulling pulling data from a separate cached page.

owzim, thanks having a look and testing. I don't really know, as saving the page doesn't remove or modify the ASM list, just delete blocks that aren't selected anymore. The dropdown isn't actually meant to be displayed anyway. I have no plans to do so. I used the ASM select for now as it provides some simple setup and allows for an edit link to the selected items. I found it has some issues using it that way as I'm bound to what it can do or how it does it. I think the ideal way will be to create a new page field widget (like autocomplete does too) so we have full control over the functionality, and are free to create the list item as it would fit. Also to distinct them from ASM and other page field selects. Actually there's now 3 different modals/lightboxes. ASM select edit feature has jquery ui modal, creating blocks has a fancybox modal, frontend uses Fredi modal. Again this is meant to get it working quickly and I think it comes down to what I said above to use one and the same for all, but not sure yet as PW will soon drop fancybox as it's stoneage (1.2.6) and also won't work with jquery > 1.8. Had an error on a different fresh install. Haven't dug deeper into it, since I got it working on another install. May be some faulty setup. It comes up on page edit when pages have that pwbc_blocks_select assigned: I think I know where that error comes from (page select field custom code) but it doesn't show for me. Can you change the custom php code in pwbc_blocks_select to following and see if it solves it? $parent = $page->blocks_parent; if(!$parent->numChildren()) return; return $parent->children('include=all'); I'm not sure I understand. The prefix is the most simple way for the module to recognize the block templates. It has nothing to do with where the template file is located. The module needs to know them so it can change the template filename on runtime so we it can simply call render on the block pages. BTW by "helping out", I actually meant "coding" not testing But testing is also appreciated and needed. Thanks

Oky doky. v 1.2.1 # added support for nav_selector property/field and selector_leveln (new in 1.2.1) You can now add a special property "nav_selector' to page(s) to define custom selector for rendering their children. This can be done on runtime or via a custom field added to pages to remotely control the selector. You can configure the name of the field by using the newly added option "selector_field". MarkupSimpleNavigation will look out for it and use it, otherwise it will use the "selector" option. You can now define selector on a per level basis. Simply use the _leveln suffix on the "selector" option, where n is the level number from the root parent. This is best illustrated by the following example: $pages->get(1001)->my_selector = "template=projects"; $options = array( "selector_level1" => "template=ressort", "selector_level2" => "start=0, limit=10", "selector_level3" => "template=news|events, sort=-created", "selector_field" => "my_selector" ); echo $nav->render($options); Note that "my_selector" has priority and will overwrite any other selctor or selector_leveln https://github.com/somatonic/MarkupSimpleNavigation

I'm currently playing around a little and I might have a very elegant solution that you could: 1. Give a page or pages a "$page->selector" on runtime that the module will look for. So you could specify on every page what children selector it will have. This could then even work if you create a special field to attach to templates to make it configurable in the admin. $pages->get(1001)->selector = "start=0,limit=10"; 2. and have selector options "selector_leveln" that you could (dynamicly unlimited) use and the module will look for it, if found use that instead of the $options['selector'] "selector_level1" => "start=0,limit=10"; "selector_level2" => "start=0,limit=20"; All quite simple to implement and seems very powerful. How does that sound?

I've encountered a problem with my contact form. Characters such as å, ä and ö in mails sent from the form are displayed as Ã¥, À, and ö. I'm sure it has something to do with character encoding(utf-8, iso-8859-1). I've googled around for a solution but couldn't find an answer Any ideas how to fix this? Here's my contact form code: // set this to the email address you want to send to (or pull from a PW field) $emailTo = ''; // or if not set, we'll just email the default superuser if(empty($emailTo)) $emailTo = $users->get($config->superUserPageID)->email; // set and sanitize our form field values $form = array( 'namn' => $sanitizer->text($input->post->namn), 'epost' => $sanitizer->email($input->post->epost), 'meddelande' => $sanitizer->textarea($input->post->meddelande), ); // initialize runtime vars $sent = false; $error = ''; // check if the form was submitted if($input->post->submit) { // determine if any fields were ommitted or didn't validate foreach($form as $key => $value) { if(empty($value)) $error = "<p class=\"error\">Kontrollera att du har fyllt i alla fält.</p>"; } // if no errors, email the form results if(!$error) { $subject = "Kontakt formulär"; $message = ''; foreach($form as $key => $value) $message .= "$key: $value\n"; mail($emailTo, $subject, $message, "From: $form[epost]"); $sent = true; } } if($sent) { echo "<p class=\"success\">Tack! Ditt meddelande har skickats.</p>"; // or pull from a PW field } else { // encode values for placement in markup foreach($form as $key => $value) { $form[$key] = htmlentities($value, ENT_QUOTES, "UTF-8"); } echo $error; ?> <article role="complementary"> <form action="./" method="post"> <p> <label for="namn">Namn</label> <input type="name" id="namn" name="namn" aria-required="true" value="<?php echo $form[namn] ?>" required> </p> <p> <label for="epost">E-post</label> <input type="email" id="epost" name="epost" placeholder="du@domän.se" aria-required="true" value="<?php echo $form[epost] ?>" required> </p> <p> <label for="meddelande">Meddelande</label> <textarea id="meddelande" name="meddelande" aria-required="true" required><?php echo $form[meddelande] ?></textarea> </p> <input type="submit" id="submit" name="submit" value="submit"> </form> </article> <?php } ?>

To problem 2. After testing we found that in where the language suddenly changes from "fr" to "default" is where we in API modify a user (not current) and save it. Afterwards the $user->language is set to "default" of the current user. THe culprit seems to be that after $page->save() there's a uncacheAll called which cleans out the $user->language set on runtime. We have now a workaround to save language before to a var, and give it back to the $user after the save. But it looks like when saving a user in front-end the $user->language set by the language system is reset.

Well, if that template protocol/https setting doesn't work when changed runtime, you can always do the redirect too. Something like this: <?php if ( ! $config->https) { $httpsUrl = str_replace("http", "https", $page->httpUrl); $session->redirect($httpsUrl); }

Nice work Adrian. I would definitely add formatted option too. Btw: is that how you you format phone numbers in US? Here phone numbers look like this +358 4143 8399 1 (not sure about spaces). Maybe allow few runtime options for different localizations?

I guess my main concern is that dimensions for things are rarely whole numbers (integers), so I am not sure how useful the module can be in its current form. Maybe not an issue in the metric world (where I was born and raised) where you could specify dimensions in millimeters, but now that I live in a backward imperial country (practically, although not officially), and we are stuck with inches as the smallest unit of measurement, it becomes a problem. I am not completely convinced on these multiple input field types. I have always set up dimensions as three separate fields and done the calculations at runtime (I also don't like the redundancy of storing calculated values), but I was looking for a way to use the volume in a selector and thought this might be a good approach. Makes me wish for the ability to do math and apply other calculations / functions to the items in a query, but you have heard my thoughts on that before EDIT: Apologies - I just properly read and understood your instructions - you are saying to store as 538 and format on output to 5.38

There's maybe. Because I'm lazy and do number_format($page->dimension->width/100, 2). I'm not really sure, but I never want(ed) to support a setting for float, as my experience with it is mixed and it would mean to make it a lot more complex than I really wanted for a first basic first version. Make it configurable may be possible but I currently have no plans. Also there's endless possibilities and I could also ask why not also support only w&h and volume and area etc Keeping it integer makes it more straight forward. I could also imagine instead consider making a module that does formatting for the field for you, I think it would be more ideal to do the calculation 130/100 on runtime, instead of making a modified version of the field.

Because permission inheritance is determined at runtime. Two pages using the same template can inherit different permissions based on what templates their parent pages are using. To put it differently: when a page is using a template that does not define access, then that page is going to inherit the access from the nearest parent page using a template that does define access. As a result, if you only define access on your homepage template (which is the default setting) then those access settings are inherited throughout the entire site. But then if you had a page called /private-stuff/ that was using a template called "private", and that template defined access, then any pages below /private-stuff/ would inherit the access defined on the "private" template. The only exception would be if one of those pages used another template that itself defined a different access.

What you are looking for is probably $page->localName($user->language). The LanguageSupportPageNames module modifies the output of $page->path() / $page->url(), but not $page->name. That's because it's kind of a primary identifier for a page that needs to stay consistent at runtime regardless of language.

Here's what the code actually says. In the Page class, we have these constants: const statusOn = 1; // base status for all pages const statusLocked = 4; // page locked for changes. Not enforced by the core, but checked by Process modules. const statusSystemID = 8; // page is for the system and may not be deleted or have it's id changed (everything else, okay) const statusSystem = 16; // page is for the system and may not be deleted or have it's id, name, template or parent changed const statusHidden = 1024; // page is excluded selector methods like $pages->find() and $page->children() unless status is specified, like "status&1 const statusUnpublished = 2048; // page is not published and is not renderable. const statusTrash = 8192; // page is in the trash const statusDeleted = 16384; // page is deleted (runtime only) const statusSystemOverride = 32768; // page is in a state where system flags may be overridden const statusCorrupted = 131072; // page was corrupted at runtime and is NOT saveable const statusMax = 9999999; // number to use for max status comparisons, runtime only These are all the possible values for status. However, status is a bitmask, so it can have more than one value at a time. However, the status levels are ordered from most visible to least visible, so selectors like "include=all" actually translate to "status<9999999" and "include=hidden" translates to "status<2048". Next is the PageFinder class, which is where the "include=all" and "include=hidden" are defined, among other things. There is also an internal mode in PageFinder called "findOne" that is an option that the $pages->get() function uses. The findOne option is not one that you would use on your own, it's only an internal designation. The findOne option states that: 1) return only the first match; 2) skip over any access control checks; 3) limit to pages with status less than unpublished (unless another status is specified or include=all is specified). There is also the "findAll" option, which is what is assumed when you specify "include=all". That one states that 1) the status must be less than statusMax (meaning, it can include any available status); and 2) skip over any access control checks. Again, you don't need to remember what findOne and findAll are, since you won't ever use them. But I mention them just to explain how selectors translate in the system. $pages->get() or $pages->find() are not going to include pages in the trash unless you specify an "include=all" or one of the high status levels. $pages->get() is different from $pages->find() in these respects: $pages->get() only ever returns 1 page. $pages->get() bypasses access control and will include hidden pages. You don't need to specify "include=all" to $pages->get(); unless you want to retrieve an unpublished page or a page from the trash. If there are times when you want a $pages->get() that performs exactly like $pages->find(), except only returning one page, you can do this: $page = $pages->find("your selector, limit=1")->first(); if($page) { // you got it } Or you can do this: $page = $pages->get("your selector"); if($page->viewable() && !$page->isHidden()) { // you got it } I almost never need to do any this though (or necessarily even remember it). $pages->find() behaves the way I usually want it to, including things that aren't viewable and things that don't belong in lists and navigation. And $pages->get() behaves the way I usually want it to, returning the single specific thing that I asked for.

The loadPageField() method is what loads the raw value from the database and returns it as an array. Most Fieldtypes just inherit the base Fieldtype method of doing this. But in this class, it has to be implemented since it doesn't actually load anything from the DB. The wakeupValue() method is what gets called to convert a raw value (typically an array) to an object, if required by the fieldtype. For instance, the Page reference Fieldtype converts it from an array of page IDs (numbers) to a PageArray of Page objects. If the raw value doesn't need any conversion to something else, then the function can just return the raw value. wakeupValue is typically dealing with values loaded from the database (via the loadPageField method). But wakeupValue can't assume that, it doesn't know where the value came from... it could have come from some other web service, data source or import function. That's why loadPageField and wakeupValue are separate things, and both necessary. The sleepValue() method is the opposite of wakeupValue(). It converts the value from a runtime representation back to a raw representation, suitable for storage in a DB or web service feed, etc. For instance, in the Page reference field type, it converts the value from a PageArray back to a regular PHP array of page IDs. If the page is being saved, the savePageField() receives the value generated from sleepValue() and saves it to the DB. It expects that value to either be a raw value: array of [column => value], string or integer. Like with loadPageField, most Fieldtypes inherit this from the base Fieldtype class. Lastly is the formatValue() function, which is what is used to provide any additional front-end, runtime formatting for a value where necessary. For example, text-based Fieldtypes use this to run formatters like Markdown or HTML entities. The formatValue function is only called if the "output formatting" mode for the page is ON. The formatValue() function is called on every access to $page->your_field_name, so the unformatted value is always still retained with the page. Given the above, there are a few different ways you could approach implementation of these functions. For instance: Make loadPageField return the result of runSelectorQuery Make wakeupValue return the value it's given, assuming it's a PageArray. If it's a regularly array, assume it's page IDs and convert to a PageArray. Make sleepValue convert the $value (PageArray) it's given to an array of Page IDs and return that. Another possible approach: Make loadPageField return the selector string Make wakeupValue convert the selector string to a PageArray (calling your runSelectorQuery) Make sleepValue return the selector string In this case of this Fieldtype, you'd basically just have to think about how you'd want the value represented externally in a CSV file or web service (for instance). Would that be an array of Page IDs or the selector string the generated them? The selector string may be more portable in that context.

Hello Ryan, thank you for your time looking into this. If I placed a message at 2 spots, I am sorry. Maybe by mistake. You can imagine what the effect of this change is, I am flooded with phone calls from editors and started to pin down this subject several times today already fulll of interruptions. Funny thing is: everything worked for weeks and the only thing I was permanently keeping up-to-date was the dev version of wire since the switch to PDO. Shortly after the 21th July update things went bad and I discover more and more, to what extend. We use multi-language-supprt but not LanguageSupportPageNames. (We solved this differently by allowing local editors to changes file names in language branches and catch files in find() and gat() over a permanent field.) Before the dev update from 21.July I was running the previous dev version. No problems at all. It can be, that the permissions are changed at runtime. If I look at the templates permission settings, everything's fine there. Yes I use field-permissions, basically to secure certain fields that are too powerful like html textareas without filters for certain JS. (What was not changed in runtime bur for real was the unpublishing rights) Fields permission: From what I know, first the permissions for a page are set and then there is an exception for certain fields that are more restricted, correct? Our templates are as simple as they can. We only display, we do not save. One exception to mention: Looking for save() revealed a template in my backups which was in use at the time when the trouble started. That shows an analog clock. It has a save() in the JS somewhere. (This script is not in use any more because we found something better.) Was that the trouble maker and not wire? File is included as "oldfile.php". Addition: The new Clock Code (march.js) we use also uses save() in it's JS .... this has somehow to do with drawing inside of a canvas. And the external script is handled by PW like this: $config->scripts->add($config->urls->templates . 'scripts/clock/march.js'); Maybe there something gets executed that should not be. I can say now that the time the trouble started was exactly when implementing this widget. Thats what I meant when saying we were not changing things in PW but were only adding visual gimmicks at that time.

@ceberlin: not a problem, but for the future please try to avoid posting the same message in two topics–I see this same message as a new topic, so I'll delete that one and reply to this one. It sounds like you are using a module that modifies ProcessWire's default access control: Page Edit Field Permission. So it's very possible that the rights you see in your page settings are incorrect. Instead, pay more attention to what your templates actually say, and how you've configured the PageEditFieldPermission module. Those have authority. The info you see in page settings is an informational-only table that reflects known static permissions and says nothing about runtime permissions attached from other modules or hooks. Most of the changes in the dev branch are specific to the LanguageSupportPageNames module and multi-language support in general. Are you using LanguageSupportPageNames or any kind of multi-language support? When you updated to the newest dev version (2.3.2), what version were you running before that? I replied to your comment on GitHub: Why linking to the mod settings pages in the admin of your site? I was thinking it might be because you want me to look at your settings for those modules, but note I can't see them since I am not logged into your admin. Are there any other 3rd party modules you have installed? If so, can you mention them, or post a screenshot. We'd want to see all modules that appear on the "site" tab of your modules screen. Also, since all of this is rather mysterious, I would also suggest checking your template files. Do you have any instances of save() in any template files or files they include? If I had experienced the same issues you have, the first thing I would do is check where I am saving pages (or anything else) in my site. I would suggest doing a: grep "save()" /site/templates/* Please post the code for any sections that perform a save of anything in your template files.

Once a system has a page-publish permission, it changes the behavior of page-edit as well. From that point forward, a user with page-edit permission must also have page-publish permission in order to edit a published page. The "who can access this page?" screen is telling you as much as it can about individual roles, but it's not telling you anything about combinations of roles. If a page is published, and there is a role that has page-edit, but not page-publish, then it's going to say it's not editable by that role. And that's true, because if you take that role by itself, the page isn't editable. Likewise, if you've got a role with page-publish, but not page-edit, a user with that role by itself can't edit anything. So this information section can't tell you anything about what might be the results of combining roles. Since that is determined at runtime, specific to a user, the only way you can tell is to try it with an actual user. Before I experiment too much here, I should check if you are testing by logging in as the user, or just by looking at what this info screen says? Stacked permissions should still work for the actual user at runtime. Though let me know if you find they aren't? These settings are cached with the template. So it may say one thing here based on that cached state, but again the runtime result of the actual permissions for a user should be consistent with the user's actual permissions. Let me know if you find it is not, as that would be a bug. I agree this must look confusing. Those checkboxes are getting populated with the cached value from the template. It sounds like what I need to do here is prevent "disabled" attribute checkboxes from having a checked value.

Hey mindplay.dk, yeah good idea. I just added support for volume value that will get calculated once a dimension value has changed. This value also gets saved to the DB. To add a runtime computed value it's very easy, but unfortunately then it wouldn't be possible to query volume using selectors. Much like the concat fieldtype of Ryan.

Thank you for your replies, I learned many things from these tutorials. I received this error after PW installation. Error: Exception: DB connect error 2005 - Unknown MySQL server host 'Config' (1) (in /var/lib/openshift/51d44a53e0b8cd3e1d0000d3/app-root/runtime/repo/php/wire/core/ProcessWire.php line 96) This error message was shown because /install.php still exists. Error has been logged. Remote config file remained unchanged during installation! To solve this error, I followed steps below after installation: - deleted local install.php file and site-default/install folder - updated local config file with new mysql connection & userAuthSalt parameters - git add . - git commit -a -m 'Delete Setup Files & Update Config File' - git push - checked remote config file. it has correct db parameters. However, I still get DB connect error 2005 - Unknown MySQL server host 'Config' error. Do you have any idea? Did you get any missing db config error after your installations?

Currently I can't see any reason why this wouldn't work. But a few things you might try: 1. Clear your opcode (APC?) cache. I do this whenever I encounter something odd that doesn't add up. 2. Clear your modules cache. You can do this by clicking "check for new modules" on the Modules tab. 3. Check your Comments field settings. Is it set to redirect after post? Try disabling that option, temporarily, to see if it makes any difference. 4. While I'm not aware of any issues related to this in PW 2.3.0, maybe try switching to the dev branch (2.3.1) just to change things up. Also: Uninstall your module. Then click "check for new modules", then re-install it. I'm wondering if it maybe started out as NOT autoload, and that setting got cached in the DB. PW doesn't load all the module settings at runtime, as it caches some of them, especially autoload status.

Hello everyone. My problem today: i have a custom module built by Antti Peisa which hooks into the comments module that comes with PW and adds a ratings field. Antti did an awesome job with it, except i'm not able to sort pages by their average rating. that happens because the average rating is not stored into any db field, it's just calculated at runtime, on request. since Antti unfortunately doesn't have any time to help me with this beyond a quick pointer, i'm posting here. please see the bottom of this post for Antti's comment ratings module. My attempted solution: build a module that stores the average rating for a comments field in another field, as an integer or float: i built the module lke this class PageAverageRating extends WireData implements Module { public static function getModuleInfo() { return array( // bla bla, removed for brevity ); } public function init() { $this->addHookAfter(CommentRatings::processRatingInput, $this, 'copyAverageRating'); } public function copyAverageRating($event) { $page = $event->arguments[0]; // we're interested in product pages only if($page->template->name != 'product') return; // copy the average rating into another field, if there is a rating if(count($page->product_comments) > 0) { $page->average_rating = $page->product_comments->averageRating; } else { $page->average_rating = 0; } } } i obviously had to hook it to the moment a comment gets added. Didn't really know how to do that. Antti said: so i turned processRatingInput into ___processRatingInput to make it hookable - i doesn't seem to have worked, see below Where i'm stuck: when i run the module above with the hook: $this->addHookAfter(CommentRatings::processRatingInput, $this, 'copyAverageRating'); i get an error saying: Error: Undefined class constant 'processRatingInput' (line 16 of ..../public_html/site/modules/PageAverageRating.module) Other things i've tried: Since this should be a method and not a property, i tried: $this->addHookAfter(CommentRatings::processRatingInput(), $this, 'copyAverageRating'); i get an error saying: Error: Undefined class method 'processRatingInput' (line 16 of ..../public_html/site/modules/PageAverageRating.module) Also i've tried hooking into the CommentFormWithRatings class which extends the CommentForm class and actually contains the processRatingInput() method: $this->addHookAfter(CommentFormWithRatings::processRatingInput, $this, 'copyAverageRating'); Error: Class 'CommentFormWithRatings' not found (line 16 of ..../public_html/site/modules/PageAverageRating.module) I'm attaching the module that Antti built here - it's going to be public anyway. CommentFormWithRatings.php CommentRatings.module Can anybody please help me out ? I feel like the village idiot for not managing to figure this out. How do i make this hook work? Big thanks!

I recommend adjusting your MySQL fulltext minimum indexed word length. Search this forum for "ft_min_word_len". Phrases should work with %= but the phrase you are searching for would have to be identical to the words it matches. Meaning if you searched for "white tea", it would only match pages containing the phrase "white tea", and not pages that have the words "white" and "tea" separated. Another thing to mention is that your full query above included "path", which is not query-able since it is generated at runtime (not in the DB). You can make it query-able by installing the PagesPaths module included with the core, but I don't think it can be part of an OR "|" set of fields. I recommend removing "path" from your query logic, as chances are the path is based on the title anyway. It sounds to me like what you really want is the "~=" operator, which will match all the words regardless of where they appear in the copy. Given that, tweaking your MySQL fulltext minimum index size (ft_min_word_len) would be worthwhile. See more details about how the different operators work here: http://processwire.com/api/selectors/#operators

I'm not sure that I follow everything here. But if you are getting 1 fewer pages in the role_editable_pages than you expect, that seems to imply that something has removed a page from it at runtime. Looking at the above code, the only place that I see where a page is removed is here: $p = $parents->pop(); You might try commenting out that line to see if that's the culprit. Or if commenting it out will result in some kind of infinite loop, you could just echo the contents of it like $this->message("pop: $p"); ...I'd be curious if it's popping the /about/ page.

There's no thing as to change a file field to a image field on runtime just for if there's an image. There's no standard way as it's not meant to be used that way. The only easy way would be to create a new Pageimage with the file. This requires an image field attached to the page in question so it can use that. foreach($page->files as $f) { if($f->ext == 'jpg'){ $image = new Pageimage($page->images, $f->filename); echo "<img src='{$image->size(100,0)->url}'/>"; } }

Hi all, I have a situation in which a user can upload a file that's any one of a number of formats (pdf, mpg, jpg, etc.). If the file is an image, I want to do some resizing. However, when I call ->size(###,###) on the file field when an image is in it, I get an error. Makes sense. I'm hoping there's an easy way to solve this without needing to create a separate field for image uploads. I tried following @Soma's advice from this thread, but kept getting an error from ImageSizer saying I was passing in invalid format. I know the file in there is an image as it's getting displayed in the browser. So, is there a standard way to convert a File field to an Image field? Thanks.