ryan

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");

We don't have something like this built-in at present, but here are a few options: 1. Security through obscurity. Use a filename that it going to be impossible for someone to arrive at without actually seeing the link to it. The problem with this is that someone can save the link and forward it on to others. 2. Place the file somewhere outside of your web accessible files and use a PHP script (or PW template) as a download passthrough. I can provide an example if you are interested. 3. Use http authentication on the page's /assets/files/ directory. Using cPanel, SSH or whatever tool you have, secure the directory with a password. However, the user viewing the page will need to enter a password before it'll let them download the file.

Looks like a great tool! Thanks for posting. I need to try this one out.

Great site Evan! Very unique, attractive and interesting how it all works. One of my favorites. What are you doing in terms of caching? Using the MarkupCache module or more template caching?

Thanks, I'll add this capability to the hooks API.

Thanks for reporting back, glad you got this figured out. I was just going to reply that I had no idea because PW does not touch PHP's $_SESSION var, other than adding a key to it for PW's session data.

If it supports fulltext searching, it might be technically possible in that regard. Though the implementation definitely looks different than MySQL. But I don't know much about SQLite beyond that, as I've never come across a hosting environment where SQLite was an option and MySQL wasn't. Would there be much demand for SQLite support?

This is the method that I use and find it really handy. The main.php file for processwire.com has this at the top: if(strpos($page->body, '<p>https://www.youtube.com') !== false) { $replacement = '<iframe width="640" height="360" src="https://www.youtube.com/embed/$1" frameborder="0" allowfullscreen></iframe>'; $page->body = preg_replace('#<p>\s*https://www.youtube.com/watch\?v=([^\s&<]+).*?</p>#iu', $replacement, $page->body); }

The FieldtypeFieldset* fields behave differently than the rest. This is a detail we should probably look for and answer in the field cloning, so glad you found that. Though also want to mention that you can use any FieldTypeFieldsetClose field to close any FieldtypeFieldsetOpen, they don't necessarily have to be matched in name... but it helps just to keep things organized.

Svet, apologies this message didn't show up in my new content list for some reason (I'm still learning the ropes of IP.Board). There are a couple of different approach you could take with this: 1. Let 1 textarea called 'quotes' serve the need instead. Use a regular textarea field (not TinyMCE) and enter each quote on it's own line. $quotes = implode("\n", $page->quotes); The quotes are now in an array called $quotes. You can iterate that array or pluck one randomly like you would if they had started in separate fields. 2. Or, you can create a 'quote' template and use a separate page for each quote. This is probably the approach I would take. You can select, iterate or pluck them randomly like you can with any other pages. For instance, if you wanted to output a random quote: $quote = $pages->get("parent=/tools/quotes/, sort=random"); echo $quote->body; Please let me know if I can provide additional examples.

There shouldn't be any overhead with using the multisite feature. All it's doing is checking $_SERVER['HTTP_HOST'] to determine what /site/ directory it should use, and that doesn't represent any overhead. I'm not sure I understand. Are you saying that something is not working how it should, or that restarting the server fixed it? B)

Nico, we can't put those in like that just because they translate differently into other languages. We actually did originally, but then learned that it was producing an incorrect translation in Finnish and Russian. However, you can configure how you want these translated in Modules > Inputfield > InputfieldPageName

Looks like I forgot to remove a line in the code. You are right, it wasn't working. Sorry about that. Grab the latest /index.php and try again and it should work. Thanks, Ryan

Diogo, a couple things to check: Make sure that your /index.php and /.htaccess files are both brand new from PW 2.2. Next, I suggesting adding both 'www.mydomain.com' and 'mydomain.com' to both go to /site-testing/. Lastly, if /site-testing/ is just a copy of your /site/ dir, then make sure you've updated something in your /site/templates/ to reflect that, so that you can tell the difference. For instance, have /site-testing/home.php have something like "echo "<h1>Site-testing</h1>";

I just downloaded a fresh/blank copy of PW 2.2 and installed this module just to make sure it didn't have anything to do with the dev site I had tested on before. But it's working as expected, creating the dir in the right place, etc. So there must be something else that I'm missing. The behavior you are describing definitely indicates a core bug. I can't think of any other possibility. I'm going to do more testing here and hope to find and push a solution shortly.

I was planning to keep it in P21, but of course the name is no longer reflective of the version. I think that others do it by just keeping their original one, like ProcessWire (rather than P21). This comes from me being a Git newbie, I didn't know how to use branches when I started. But now we've got all of our "watchers" on P21, and I'd hate to lose them. So not exactly sure what to do? But perhaps we'll take over the ProcessWire repo once again with v2.2.

Can you confirm that you still get this same error message and that your ProcessWire reports it's version number as 2.2? thanks, Ryan

Great ideas, keep it up! I'm planning to use this SocialTwitter module on the new PW site so that every time a new module or site is added, it'll automatically post to the Twitter feed. This is going to be a big time saver.

The one I was testing with did have 2 TinyMCE fields (body and sidebar). Just went back and tested again, trying to reproduce in both of them, but no luck. I am running 2.2, which uses a newer version of TinyMCE than 2.1. I'm wondering if this issue might already be resolved in 2.2 by that update? Let me know if you have a chance to try this with the latest version and if it still occurs? Thanks, Ryan

I understand -- I think that's a good reason for us to add a replace hook. For my own testing when implementing this, can you tell me which function it is that you are hooking into?

Tested here too and it uploaded just fine. At just under 2 megabytes, I doubt you are hitting a server size limit, but it's something to look at if smaller images upload without a problem. What version of Firefox are you using and have you tried in any other browsers? Do you have any 'max dimensions' set in your image field?