ryan

There's no getting around people using fake names, regardless of Twitter or Facebook. But at least we've got Akismet to provide some level of spam protection. I think remembering the user's info in a cookie is a good idea either way.

Thanks guys, this is good to know. I will definitely plan to implement in FieldtypeComments. On a related point, any idea how we can automatically identify the users info if they are logged into Twitter or Facebook? Obviously we won't be able to get their email, but perhaps we can get their Twitter/Facebook name and maybe gravatar hash automatically? I have no idea if it's possible, I really haven't played around with the APIs of these services at all. But seems like I've come across sites that were identifying me in this fashion (or I might have mistaken JS-based widgets originating from Twitter/Facebook).

Thanks Nico, that is nice and simple. I think we'd also need to cache the avatars locally for some period of time, to avoid DOS'ing the gravatar servers. One page with a dozen comments would fire of a dozen requests to gravatar.com. Maybe that's okay? Are you aware of any rules or best practices in this regard?

Glad they were able to turn off safe_mode for you there, and that all is working now. However, I think there is something more than just safe_mode at play here, because it really shouldn't be preventing PW from creating its assets folders. Having the install script create the assets folder doesn't help us here because then that would just throw the question back to the previous directory. If we can't create /site/assets/files/ then it's reasonable to assume we also can't create /site/assets/ ... all the way back to the web root. And ProcessWire can't create the web root. I'm guessing Apache was running under something other than your account, and the fix under safe mode would have been to change the /assets/ directory ownership to whatever user Apache was running as. But I can't say for certain. Just glad you convenced them to turn off safe_mode, as I think they are a lot better off now.

This inputfield uses the ProcessPageSearch AJAX API, which is accessible to logged-in users only that have administrative access. Meaning, it can't be used on the front-end of a site, unless for an administrative user. However, this Inputfield is mainly just a front-end to the jQuery UI autocomplete, with some tweaks to make it consistent with PW's admin style and offer some configurable options. So one could very easily implement the same sort of functionality on the front-end of a site by creating a page with it's own template to handle the ajax calls, translate them to a $pages->find() operation, and return the matches. It doesn't need to do any more than this: /site/templates/search.php <?php $resultsArray = array(); if($input->get->q) { $q = $sanitizer->selectorValue($input->get->q); $results = $pages->find("title*=$q, limit=50"); foreach($results as $p) $resultsArray[$p->id] = $p->title; } echo json_encode($resultsArray); From there, the rest is just jQuery UI autocomplete: http://jqueryui.com/demos/autocomplete/#multiple-remote

Good feedback, thanks Nico. The comments module is kind of weak right now, so it needs some attention very soon. The long-term plan for the 'Comments fieldtype improvements' is to convert the comments system over to use pages instead. The goal with converting them to pages will be to make them really accessible and searchable from the API standpoint. It'll also mean that you'll have a 'comment' template that you can add whatever fields you want to. However, we'll likely make improvements to the existing Comments fieldtype before this. In fact, I've already built a new ProcessComments module that adds a 'Comments' option to your admin top nav, and lets you manage comments separately from pages... just haven't committed it to the core source yet. I will take your suggestion to add a website field and keep track of the email/website in the user's session. Some of this is at the discretion of how you utilize it. I recommend doing your comments output generation and processing before you send any output. When a comment is added, make your page redirect back to itself to both prevent reload-duplicates and start with fresh DB-loaded data. This also ensures that the user will see their comment rather than a "thanks" message (great if you aren't using a moderation queue). This is not already in place. I thought I saw this on your stadtpirat site? Do you know how to do it? I'll add it if you tell me how....

Adam, you are right about this one. Tried it myself and got the same exception you did. Thanks for finding it -- It's a bug in the Pagesfiles::remove function that was preventing it from working with keys. Just fixed it in the latest commit.

Hani I think you've got a good and smart solution here. Nice work coming up with this. My only concern is just that it sends all file accesses through that script rather than just the ones it needs... but obviously there's no simple answer to this problem. There is significant overhead with doing a passthrough, relative to a regular file access, and I think the effect would be noticeable. So a passthrough is one of those things you only want to use when you have to. But if we're not talking about a high traffic or performance-critical situation, then this solution may be just fine. For a core solution, I think we'd take a similar approach, but in a manner that can separate the private from the public really easily, so that no public files are going through passthroughs. One suggestion though: Change your $pages->get($_GET['page']) to this below, just to ensure you aren't sending unfiltered data through an API call, and that you are dealing with a page that exists: if(!$input->get->page) throw new Wire404Exception(); $page = $pages->get((int) $input->get->page); if(!$page->id) throw new Wire404Exception(); I'm not sure we could take this approach unless the /site/assets/files/ directories get moved to another location to separate them from the 'public' files. Otherwise, that htaccess file would have to know every page ID for protected pages. But I think separating the dirs is the right way to go. Either that, or renaming protected page file directories with a "." in front of them, i.e. /site/assets/files/.1234/ That way, the htaccess file can recognize them ahead of time in a predefined manner. And PW's htaccess already blocks any files/dirs that start with a period. Because your site is installed in the root of your domain. If it was installed in a subdirectory, then it would return the subdirectory. Also, like Pete mentioned, ProcessWire does not usually include the schema and domain in any 'url' function/property unless you ask it to. At this point I think you are more of an htaccess guru than 99% of web developers. But to answer your question, unless you put in USER_AGENT rules, your htaccess file doesn't know or care whether it's a search engine spider or a real user coming through. It's going to exhibit the same behavior on both. Meaning, it will prevent indexing of protected files.

This is a good link, but actually we're trying to figure out how to do it from just the video URL rather than the embed code. If we've got the embed code, then figuring out (or proportionally scaling) the dimensions is no problem. But TinyMCE won't take an embed code by default, so we're trying to embed videos, knowing nothing but the URL to them. Kind of like how this forum, IP.Board does. Though it looks like IP.Board just uses a predefined width/height rather than trying to figure out the video's dimensions. And I'm thinking that's the same approach we'll have to take.

Michael, I just added the PageAutocomplete to the core (and got your tweet that you already saw it). I wanted to mention that after you save your field settings with 'PageAutocomplete' as the input field, you'll see some more configuration options appear on the 'Input' tab. This includes what operator you want to use (like %= vs *=, etc.), as well as what fields you want it to search.

ProcessWire will give you a warning at install time if the /site/assets/ dir isn't writable. This part really shouldn't matter with regard to safe_mode. Ejdamd, is some part of PW not working in your case? Let me know, as PW should be safe_mode compatible. But if you are finding it's not we can find out why not and tweak as needed. Also, I would suggest sending your provider this link. The PHP team strongly recommends not using safe_mode. Servers relying on it tend to be less secure, not more secure. They have deprecated it and it won't be around much longer: http://php.net/manua...s.safe-mode.php

Michael, I just replied to a PM from someone else about this, so it's quite a coincidence for the next message I read to be on the same topic. I'd already started an autocomplete Inputfield using jQuery UI some time ago, and just never got around to finishing it. Since it's come up again, perhaps now is a good time for me to finish it. If you are only dealing with ~1500 street names there won't be much if any noticeable performance hit from %= vs *=. Granted *= is using an index and %= isn't, but 1500 items is chump change to MySQL, especially with something short like street names. When you use *= or %= (as opposed to ~=), note that those are wildcard searches when used with single words. They will find all words matching or beginning with the specified term. Meaning a search for "start" will also match "started", "starts", and "starter" (as examples). Also take a look at the ^= and $= operators, which will match at the beginning or end of a string. We are pushing the limits of what a fulltext index will let us do, but you can get more wildcard type options using a MySQL LIKE query directly to have something like "st_rt" match "start" or "%start" match "restart". I've not found these to be useful in my own web development projects so haven't implemented them into PW operators. But we may bring more MySQL LIKE and REGEXP commands into PW selectors in the future. My feeling is that I don't really want to encourage people to use them because they aren't scalable, relying upon full non-indexed table scans. But when dealing with items at the scale we were talking about (1500) it doesn't matter much. I don't how to implement such a thing at present (with MySQL), but will keep an eye on such possibilities in the future. I believe that Google finds those 'did you mean' options by monitoring repeated search behavior at a large scale over time.

Soma I've not received your email? Maybe it's still coming through, I'll keep an eye out for it.

Good ideas. I think this is definitely an option we'll want to have at some point soon. This is actually something the first iteration of ProcessWire (called Dictator) had back in 2004. If you removed 'guest' access from a page, then it would move its files directory to a non-web-accessible location and use a passthru script to deliver files so that they could only be accessed if the user was logged into an account with the appropriate access. The need hadn't come up since then, which is the only reason why it's not already in PW. But it's one of those things that's very important for private intranets and the like, so that you don't get confidential company PDFs floating around publicly or getting indexed by Google.

Diogo, Pete is right. You can also use $this->pages if you prefer it. But the nice thing about wire('pages') is that it's a constant that works anywhere whether in or out of a class, command line api, etc.

Thanks I'll take a look at the php info. Which modules are installed? Since there have been a lot of changes committed in 2.2, it's good for me to know the full details of especially the ProcessWire environment and what modules may be coming in to play.

Thanks Soma, nice job. This is a great module!

I'm not sure why that would work when removeAll doesn't because the foreach you posted is identical to the one used by removeAll. But that's not the issue here, instead it's this: Files aren't actually removed or copied until you call $page->save(); that's what ultimately commits the change to the file system. So I think you'd solve this one by adding a $page->save(); immediately after your removeAll (before adding the other images). The reason for this is that we don't want permanent changes (like deleting files) made to pages until we're certain those changes are actually going to be saved. Otherwise temporary runtime manipulations to something like $page->images wouldn't be possible, because you'd be copying or deleting files around without ever having that committed to the database (resulting in data corruption, and lots of untracked files).

Hey Adam, we cut out of the conference early and just made it back. There's a few issues with this URL that make it not compatible. First is that I'm not sure you can pull through https with a PHP stream (though not positive). Second is that there's nothing about that URL to indicate it's a file. ProcessWire isn't going to know what to do with it because there's no filename or extension. I think you'd have to find some other way to get this saved to a file and then import to ProcessWire from there.

Exactly, any youtube URL in it's own paragraph. Soma and I collaborated on this in another thread, and I've been using it ever since. I would turn it into a module, except that I'm not really sure how to handle the width/height issue (it would need to be predefined somehow).

Soma, great idea and it seems to work great. Nice job. As for the code in there, I think all looks good except that you've got a lot of 'extra' that you don't need. I don't think there's any reason to extend FieldtypeText (?) so I would just start from a fresh Fieldtype instead: class FieldtypeColorPicker extends Fieldtype { public static function getModuleInfo() { return array( 'title' => 'ColorPicker', 'version' => 100, 'summary' => 'Field that stores a hex color as string in a text field. Color is picked using a jQuery ColorPicker Plugin by http://www.eyecon.ro/colorpicker/', 'installs' => 'InputfieldColorPicker' ); } public function getBlankValue(Page $page, Field $field) { return 'FFFFFF'; } public function sanitizeValue(Page $page, Field $field, $value) { return strtoupper(substr($value, 0, 6)); } public function getInputfield(Page $page, Field $field) { return $this->modules->get('InputfieldColorPicker'); } public function getDatabaseSchema(Field $field) { $schema = parent::getDatabaseSchema($field); $schema['data'] = 'CHAR(6) NOT NULL'; // i.e. FFFFFF or 333333 (hex color codes) return $schema; } } Likewise, your Inputfield had a lot of extra functions and stuff in there that you didn't need. So you could reduce it to this: <?php class InputfieldColorPicker extends Inputfield { public static function getModuleInfo() { return array( 'title' => 'ColorPicker', 'version' => 100, 'summary' => 'Provides and ColorPicker interface for defining hex color.', 'requires' => array("FieldtypeColorPicker") ); } public function __construct() { parent::__construct(); $this->setAttribute('type', 'hidden'); } public function init() { parent::init(); $this->config->styles->add($this->config->urls->InputfieldColorPicker . "colorpicker/css/colorpicker.css"); $this->config->scripts->add($this->config->urls->InputfieldColorPicker . "colorpicker/js/colorpicker.js"); } public function ___render() { $out = "\n<p><div id='ColorPicker_$this->name' style='border:2px solid #444;display:block;width:40px;height:40px;background-color:#".$this->value."'></div>"; $out .= "<input " . $this->getAttributesString() . " /></p>"; $out .= <<<_OUT <script type='text/javascript'> $('#ColorPicker_$this->name').ColorPicker({ color: '#$this->value', onShow: function (colpkr) { $(colpkr).fadeIn(500); return false; }, onHide: function (colpkr) { $(colpkr).fadeOut(500); return false; }, onChange: function (hsb, hex, rgb) { $('#ColorPicker_$this->name').css('backgroundColor', '#' + hex); $('#Inputfield_$this->name').val(hex); } }); </script> _OUT; return $out; } }

Thanks for following up on this, it sounds like there are some good things about SQLite. This is a great summary you posted Futuresplash. I've never looked into it, so glad to learn more here. While there's not real strong incentive to support other databases right now, it is part of what the underlying framework is designed for and may be a possibility in the future. I will keep looking into this. Thanks, Ryan

I'm wondering if the server has safe_mode or open_basedir restrictions? I can add a '@' to the front of the rename statement in Upload.php to suppress that error message, but am curious how the file is getting through if that rename is failing. Also, is this on a stock installation, or are there any non-core modules installed?

You are right that's a terrible error message! But, you shouldn't get this error message if you are running the latest PW. The latest PW will give you a better error message. However, I'm familiar with this particular error and it means that the database connection failed. Your database server was down or overloaded and PW couldn't connect to it. Since Modules are the first thing it tries to load, that query failed.

You can easily exclude pages by any factor that you want to by using a selector when the pages are loaded, or an if() statement after. Jasper was on the right track, but the example he posted wouldn't work just because $child->parent is an object and not a string. However, you could do something like this instead: foreach($children as $child) if($child->template == 'some-template') continue; // skip it // ... otherwise display it ... } Another example: // display children, except for those with parent 'products' or those using template 'employee' if($child->numChildren && $child->name != 'products' && $child->template != 'employee') { listChildrenTree($child->children); } You can also do something like this: // list children that aren't using template employee listChildrenTree($child->children("template!=employee");