ryan
-
Posts
17,307 -
Joined
-
Days Won
1,725
Everything posted by ryan
-
We may have to add a button like that soon. Currently it restores defaults when you set it to the blank/original unset value. But of course that prevents you from overriding a default populated value with an unpopulated one. So currently it's best to leave the default (no context) value blank if you want it to be blank/unset in any alternate template contexts. Luckily, I don't think that's a common situation (at least not here). I'm not sure that I understand? There isn't a foundation for context outside of multiple template/fieldgroups, but maybe I'm not reading this right. Can you give me a more specific example or what you mean?
-
Actually this sounds familiar now, I think I remember that Safari for some reason does not support drag-drop file uploads. That was awhile ago that I remember talking about this before, and figured they would have fixed it by now. It seems like Apple is not giving much love to Safari lately.
-
Ray this is fantastic! Thanks so much for writing and sharing this with us. I am setting up a case studies forum as a subforum of showcase (unless you guys think it should go elsewhere?) and will move this there. Thanks again!
-
Sevarf2, I tried to duplicate this over the weekend, but so far not having luck. My repeater had an datetime field that auto-populated the current date and also had a datepicker on it. I tried saving them, deleting them, etc. I tried this with both setting the "ready pages" number and 0, 1 and 3. I'm wondering if there might be any other factors -- Are there any other fields in your repeater? Are you using the default admin theme or another? And any other modules installed? Thanks, Ryan
-
It sounds like it really is a Page object then, as it should be. The question then is why PHP is throwing a "not object" error. I'm wondering about the eAccelerator that your phpinfo said is installed. I have a feeling that line 78 isn't really line 78, and that it's line 78 of a cached file or something. I look forward to getting a closer look at the install (per your PM).
-
TinyMCE: Color picker suggesting colors from other pages/fields?
ryan replied to Lars282's topic in General Support
To assign the class to your article, like the one in your link (a full page article) you could add the category name to your <body> tag. <body class="<?php if($page->category) echo $page->category->name; ?>"> Then in your CSS file, you would do like what Diogo suggested: body.climate #article em { background-color: #07ABBA; } -
You can do that, or you can download the ZIP and replace the /wire/ directory from your installation with the /wire/ directory from the ZIP. When not using git, I usually rename the existing /wire/ dir in my site to /wire.old/ temporarily, just in case I need to revert. Yes, everything should work in Safari. Though I would use Chrome over Safari to avoid the continuous beachballing on every site I visit with it (or maybe that's just my computer).
-
Pete, I'm still really confused about how that line 78 is throwing a "trying to get property of non-object" error. It really shouldn't matter if it says "single page or boolean false" or "single page or NullPage". Line 78 doesn't deal in that, and it's just a really unusual error. So I'm really curious to know what exactly $page is in that instance. It's apparently non-zero, non-object, which is something that $pages->get() technically shouldn't be able to return. Can you try adding this before line 78? var_dump($page); exit(); And see what it tells you that it is? Btw I don't see anything in your phpinfo that looks like a problem.
-
How to read a InputfieldImage settings from Pageimage Hook?
ryan replied to PawelGIX's topic in API & Templates
This is a good question, and one of the most advanced questions I've ever seen asked here. Here's how to do it. Unfortunately the $field context isn't available to the Pagefile/Pageimage, though the $page context is (accessible as $this->page from a Pagefile/Pageimage object). Given that, we can find the $field context like this: public function init() { $this->addHook('Pageimage::action', $this, 'pageimageAction'); } public function pageimageAction(HookEvent $event) { $field = null; // where we'll keep the field we're looking for $image = $event->object; $page = $image->page; $action = $event->arguments[0]; // find all fields of type FieldtypeImage that are part of the page we're using $imageFields = $page->fields->find('type=FieldtypeImage'); // loop through to find the one we're looking for foreach($imageFields as $imageField) { // good to get unformatted in case it's a single image field, // because it'll still be an array rather than 1 image $pagefiles = $page->getUnformatted($imageField->name); // if the image's pagefiles property matches the one with the // field we're looking at, we have a match. save in $field if($image->pagefiles === $pagefiles) { $field = $imageField; break; } } if($field) { $out = "<ul>" . "<li>Field: {$field->name}</li>" . "<li>Action: $action</li>" . "<li>Filename: {$image->filename}</li>" . "<li>advSetting: {$field->advSetting}</li>" . "</ul>"; $event->return = $out; } } To examine the result, do this: // single image field echo $page->image->action('test'); // multi image field foreach($page->images as $image) { echo $image->action('test'); } I will look closer at adding the $field context to the pageimages/pagefiles/pagefile/pageimage instances in the near future so that it's not necessary to find it yourself like this. But this is the best way to go for now. -
Thanks Soma, this is a great module and a recurring need--I think it will be helpful to a lot of people, including myself. Nice work with the good documentation too.
-
I'm not sure there's enough to go on here to say for sure. Where are you setting the $input->whitelist values? That's probably the same place where you want to build your search selector. Something like this: $selector = 'parent=/products/, '; $name = $sanitizer->pageName($input->get->manufacturer); $man = $pages->get("parent=/manufacturer/, name=$name"); if($man->id) { $input->whitelist('manufacturer', $man->name); $selector .= "manufacturer=$man, "; } list($priceMin, $priceMax) = explode('-', $input->get->price); $priceMin = (int) $priceMin; $priceMax = (int) $priceMax; if(!$priceMax) $priceMax = 99999; // or some other max value $input->whitelist('price', "$priceMin-$priceMax"); $selector .= "price>=$priceMin, price<=$priceMax, "; $selector .= 'limit=25'; $products = $pages->find($selector); if(count($products)) echo $products->render(); else echo "<h2>Sorry no products found</h2>";
-
solved Is URL segment setting no longer as per the docs?
ryan replied to alan's topic in General Support
Thanks for fixing that Soma, and thanks for finding it Alan. -
Peter originally contacted me. My schedule is overloaded in the short term, so I suggested that he post here instead. Peter also is a great guy and does awesome work and I'm confident he'd be good to work for.
-
Great module Soma! Thanks for making this and posting. The only thing I wonder is why make it an autoload module? This is one that is meant for on-demand use, so it doesn't technically need to be an autoload module. Though I agree it does make for a nicer API call: echo treeMenu->render(...); // vs. echo $modules->get('MarkupSimpleNavigation')->render(...); But I'm just thinking that if every module took this approach, PW wouldn't run as efficiently, or could even run out of memory. But I love this module either way.
-
Pete that error message you posted is very likely the issue. If you've got an error consistently being displayed, that will interfere with the ability of any ajax request to complete... the resulting JSON would be unparseable. I looked at line 78 of InputfieldPageAutocomplete.module and I'm not quite sure how it could generate that error. Can you double check that line 78 of that file is the same as this in your installation? foreach($this->value as $page_id) { $page = $this->pages->get((int) $page_id); if(!$page || !$page->id) continue; // THIS IS LINE 78 $out .= $this->renderListItem($page->get($this->labelFieldName), $page->id); } I am thinking that somehow your installation must be different, because it should be impossible (from what I can tell) for the statement at line 78 to produce that particular error. Please let me know what you find?
-
Thanks Oliver. I think the issue here is this: // offer user roles to choose $roles_field = Wire::getFuel('fields')->get('roles'); $field = $roles_field->getInputfield(Wire::getFuel('page'), $roles_field); // HERE $field->label = __("User roles", __FILE__); $field->description = __("Roles given to users created for this type of login by default", __FILE__); $field->value = $value; $field->name = 'user_roles'; return $field; Note the line I labeled 'HERE'. You are asking it to get an inputfield for the 'roles' field in the context of $page. At that time, $page is /processwire/modules/ (template admin) and that page has no 'roles' field. So I think this is unpredictable. Instead, I would suggest doing this: // offer user roles to choose $field = wire('modules')->get('InputfieldCheckboxes'); $field->attr('name', 'user_roles'); $field->label = __('User Roles')); $field->description = __("Roles given to users created for this type of login by default"); foreach(wire('roles') as $role) $field->addOption($role->id, $role->name); $field->attr('value', $user_roles); Just tested here and it works. Also, unrelated, but had a couple other things I wanted to mention: Wire::getFuel('something') is the same as wire('something'). The wire('something') is newer syntax, and you'll usually see the older syntax in the core. But I find wire('something') easier to read, so just wanted to mention that you don't have to use Wire::getFuel() unless you want to. For language translation, __('something'); and __('something', __FILE__); are equivalent. Specifying the __FILE__ saves a little overhead, as PW doesn't need to figure it out on it's own. But for something like a module config, or even your own site templates, it probably doesn't matter much. I've mainly been including the __FILE__ part in getModuleInfo() functions because those do have potential to be called on each request, so every little optimization helps there. Note that none of this is applicable to the $this->_('something'); syntax, but if course that syntax can't be used in a static function. For the top of your getModuleConfigInputfields($data) function, I recommend including something like this: $defaultData = array( 'user_roles' => array(), 'consumer_key' => '', 'consumer_secret' => '', ); $data = array_merge($defaultData, $data); That initializes defaults and makes any corresponding values in $data overwrite them (if present). But if values aren't present, then you don't have to worry about PHP complaining about uninitialized indexes when you are in PW debug mode.
-
Adam, sorry I linked to the wrong message in that thread before. Here's the instructions for the 'replace' hook: http://processwire.c...ndpost__p__7435 You don't want to call $pages->___save() unless you are using a 'replace' hook. For all other hooks, the original method that you hooked is still called (either before or after your hook). So a 'replace' hook is different in that it tells PW you are completely taking over the implementation. These have not been used a lot, and there is potential for conflicts with other modules hooking the same function. So that's why I say it's probably better to throw an exception where possible. In that case, your hook would look like this: function savePageValidation($event) { $page = $event->arguments[0]; $everythingIsOkay = true; if($page->other != $page->that) { // pseudocode $everthingIsOkay = false; } if(!$everythingIsOkay) throw new WireException("Aborted save because other != that"); } A replace hook would look like this: function savePageValidation($event) { $event->replace = true; $page = $event->arguments[0]; $options = $event->arguments[1]; $everythingIsOkay = true; if($page->other != $page->that) { // pseudocode $everythingIsOkay = false; } if($everythingIsOkay) { $event->return = wire('pages')->___save($page, $options); } else { $event->return = false; $this->error('Page was not saved because other != that'); } }
-
Thanks Sevarf2, I'll take a look at this and find a fix. Just to confirm, you only experience this effect when using a date field that's set to populate today's date?
-
Thanks guys, keep me up to date. I think this sounds like a great idea, and looking forwarding to adding it.
-
Soma, you are right it shouldn't be autoloading that JS, given that the module is not an autoload one. Turns out that the $modules->isUninstallable($class) was inadvertently init'ing the class when it did its check, so it was causing the modules init() function to be called when viewing its config screen. Just fixed this in latest commit. Thanks, Ryan
-
Thanks Antti, just fixed in latest commit. This applies to situations where you are adding a page somewhere and only 1 template is allowed (per the parent page's template family settings).
-
Great work Soma, it looks and works great! A great alternate way to navigate pages in the admin. Just tested here and it works great. Javascript error, ProcessDataTable.js line 26.
-
I totally agree with all that's been said. No need for PW to be creating directories unless they are going to be used. I would get this updated today if I could. Just dealing with a real time crunch here, so expecting to get this in place in April.
-
If I can get anyone to commit on writing a success story, I'll go ahead and add the forum. So whoever writes the first success story gets to lead the forum. Here's the catch, you have to write it and post it first. Then I'll create the forum and move the topic to it.
-
Welcome Charliez! When it comes to using jQuery on the front end, pretend that ProcessWire isn't there. Link to jQuery the way you usually would, whether through Google's CDN or by storing a copy locally in /site/templates/scripts/ (or wherever you prefer to). I think it's better that you don't utilize the same jQuery as ProcessWire's back-end because the needs of your site and the needs of PW's backend may be very different. You should also be able to upgrade one without the other. No need to have a front-end to back-end dependency like that. Using PHP in fields is generally not recommended because 1) it's not terribly efficient; and 2) It means that anyone with admin access (that knows their PHP) can bypass any and all security. The same goes for any CMS system that lets you enter PHP in fields. Likewise, the security of your server is then only as good as your client's worst password. PHP is just plain powerful, so I think it's good to limit its access to developers. Even if your client knows no PHP, a resourceful hacker may someday discover your client's crafty password ("b00b13s") and find their way in. If you give them PHP access, your web server will find most of its resources going towards running an IRC w4r3z server and DDOSing the CIA … Or maybe not, but that was my experience with WordPress last month. After all that, if you must enable PHP from your fields, you'll want to eval() it from your template. This is essentially what any other system that lets you use PHP in fields does. So if you have a field called 'php_code' assigned to your template, you'd execute it like this from your template: eval($page->php_code); I think that once you get deeper into PW, you'll find that PHP in fields is oldschool CMS methodology and not something that's really necessary in ProcessWire. With regards to blogging, I've always felt that WordPress answers just about every need in this area, so I've not tried to venture very far into that, and instead focus on the things that ProcessWire can do better than any other platform out there. Though it turns out that PW can be quite a great blogging platform (perhaps even better than WP in many respects). So I think you'll be seeing more and more pre-made options for this in ProcessWire as the platform matures. Also thanks to Sinnut, formmailer and slkwrm for the great replies.
