ryan

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

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.