ryan

For the autocomplete – I'm going to finish the new ProcessSearch module first, because that will provide the JS ajax results for the autocomplete. Luckily, that part is almost done. If you are querying something else for your autocomplete, I think you'll find it relatively simple to implement if you use jQuery UI's autocomplete. PW admin is already including jQuery UI, so that widget is already available to the admin. As for selecting from a massive list that needs to be dynamic, have a look at the InputfieldPageListSelectMultiple module, which can be enabled from your Modules tab. Here is a video of how it works: http://processwire.com/videos/page-fieldtype/ Though I'm thinking this isn't what you need because this only works for selecting pages.

Looks like a bug, thank you for finding it. There was an issue in the editor_plugin.js that I must have introduced recently when trying to get this working with IE. It was using the wrong filename (fullsize rather than resized). The in-editor resizes were still working properly, just not the modal ones. If you grab the latest commit of 2.1, this fixes that particular issue. Thanks, Ryan

The reason for this is that users in PW 2.1 are actually pages, and page names are kept lowercase for URL consistency. Some servers are case sensitive and some are not, so the only way to guarantee cross-server compatibility is enforcing lowercase. I like the idea of having either case for usernames, but it may involve a lot of changes underneath. I'll keep an eye on future opportunities to have U&LC in the usernames.

For the files not found in Safari's activity window, which files? I'm not suggesting that you change all your site files around, just perhaps your /index.php so that you can prevent some future WordPress hack from appending some Viagra ad to every page in your site. There's any number of other things such a hack might go after, so this will only exclude one type (though the one I've seen most often). But I'm not necessarily sure this is worth your effort. Since apache can write to all your files (since it's running as you), you can find some security in making some files readable to everyone, and writable to nobody (including you). In a directory list, the permissions would look like: -r--r--r-- I don't have the proper permission numbers in my head at the moment, but you could achieve it with: chmod uog+r-w index.php In plain English: With (u)ser (o)ther and (g)roup, add +®ead permission and remove -(w)rite permission. If you need to modify or replace /index.php (like during an upgrade) you'll want to give yourself write permission again: chmod u+w index.php If your site was compromised, the hacker could certainly change the permissions too, but large scale automated attacks on WordPress usually aren't so sophisticated. Another point of view: if your WordPress gets compromised, it's not necessarily a bad thing to have your /index.php writable because most likely you will know very quickly that something has been compromised... rather than finding out weeks later when the hole may have resulted in bigger problems. In both cases where I've seen a compromised WP install write to the /index.php file, it actually just resulted in the site showing a PHP parse error... the exploit didn't check if the file ended with "?>" or not, and it tried to run HTML tags through PHP resulting in a parse error. It was a great red flag alerting the client that something was wrong.

I totally agree. I love that you can drag-n-drop into the editor... I'm anxious to add full support for this. I might have to rethink some of the bad things I've said about TinyMCE.

Hi Pete, thanks for your feedback and welcome to the forums. I was confused when you mentioned "drag and drop", as PW doesn't have support for dragging images into TinyMCE. But then I went and tried it myself, and sure enough, it works! I don't know why that works as I've not coded anything to support it. Apparently it's something that TinyMCE must have built-in and I just never realized it. Did anyone else here (other than Pete) realize that TinyMCE supports this? I don't know how I missed this. So now that I know TinyMCE supports it, I think I just need to setup PW's TinyMCE plugins to recognize the event... I need to do more research to find out how to support this... give me a couple days. Until we've got that working, you'll want to just click on the image icon and select the image that way. But I'm anxious to add this drag-n-drop support, as it sounds quite convenient. Thanks, Ryan

So it's pulling from the CC images already–that's great!

The screencast looks very cool! FieldtypeImage just extends FieldtypeFile. If you look at the FieldtypeImage class, there's hardly anything in it. So the meat of it all is really in FieldtypeFile. I would suggest just extending FieldtypeFile and overriding any parts as needed. You can even override the table structure if you need it to be different. But as it is now, 'data' is just the filename, and 'description' is just a fulltext indexed MySQL 'text' field. If you wanted to, you could certainly use the 'description' field in a different way, perhaps to keep some JSON encoded data or something. I love how this works to pull images from Flickr. One question popped into my head as I was watching it. Does it search and pull from anywhere in Flickr? Or is this just for hooking into your own flickr account? I know in the US at least, if we cloned images from Flickr without adhering to the individual license requirements of each, we might get in legal trouble. I didn't know of a simple way around this because PW finds compatible types based on what classes they extend. Since InputfieldImage extends InputfieldFile, it's technically valid to use. If this becomes a larger problem with more instances in the future, we'll probably have to make the modules explicitly specify which they are compatible with.

For a production site, the recommended security is that you don't have any writable PHP files, or any directories where PHP files can be both written and executed. The only directory that ProcessWire needs writable on a production site is /site/assets/. And it's htaccess file excludes any *.php files from being executed in that structure. This may seem like overdoing it to some, but PHP is the most widely used web scripting language and so it gets targeted for exploits kind of like Windows does. So I think it's always good to take some extra precautions. These messages are only displayed to the superuser role, and they aren't a complete security check, just a few of the most obvious things. If you are still getting those messages, that means that PHP can write to the files indicated. Most likely you are in an environment where PHP is running as you (like PHPSuExec or CGI PHP). If ProcessWire is the only thing you are running on the account, then for myself, I would probably ignore the messages... but I don't want to recommend that per se, as it really depends where your comfort level is. If you've got anything else running on the account (like WordPress for example) then I wouldn't want my /index.php to be writable (or any PHP files, or directories where PHP files can be written). The reason is that a large number of automated exploits target your root /index.php file simply because it's a known common-denominator. Making it non-writable is just a small thing you can do. Because PHP is running as you, In your case, you'd have to make it non-writable to yourself. It's up to you to decide whether you think it's necessary or not. If you want to suppress those warning messages, grab the latest commit and add this to your /site/config.php file: $config->showSecurityWarnings = false;

I just committed an update to 2.1 that makes Field/Image Fieldtypes offer the option of a configurable Inputfield on a field-by-field basis. Let me know if this works for you? Thanks, Ryan

I agree I think this makes sense to be able to define an Inputfield with a given instance of a field if you want to. I will work on this.

When importing images to pages, make sure the page exists first. So if you are creating a new page, save it in your API code ($page->save()) before adding the image to it. Otherwise, PW won't know where to put the image(s) since the /site/assets/files/* directories are based on the page ID. If you are adding an image to a single-image field, you can just set the value of it to the URL, i.e. $page->image = 'http://www.something.com/some-image.png'; If you are adding an image to a mult-image field, you can add() it: $page->images->add('http://www.something.com/some-image.png'); Either of the above makes PW copy the image to it's assets and create the proper object. And then don't forget to: $page->save();

This has been fixed in the latest commit. It also pointed out something strange about PHP arrays that I did not know before. PHP will convert strings with only digits in them to be integers when used as array indexes. I had expected that an explicit string would stay a string, but apparently PHP does a type conversion of digit-based strings to integers. The solution is to add some non-digit character (like a space) to the string you want to use an array index, if it happens to consist of digits (despite being a string!). Here is a test case and the results: test.php <pre> <?php $var1 = "123"; $var2 = "456 "; var_dump($var1); var_dump($var2); $a = array( $var1 => "foo", $var2 => "bar" ); var_dump($a); And the resulting output: string(3) "123" string(4) "456 " array(2) { [123]=> string(3) "foo" ["456 "]=> string(3) "bar" } Strange, IMO.

Try writing that many words fast and not making a typo or two.

Thanks for the link. It sounds like they've gone buck wild with the adaptor pattern because they were stuck between a rock (MoveableType) and a hard place (needing to do more than an elderly blogging engine can do). I think that the author accurately describes the state they got when freed from the shackles of an old CMS they've been using for a long time. But I also don't think the author presented a good understanding of the overall CMS landscape outside of the platform they were using (MoveableType) and perhaps less so WordPress and Drupal. The article would be more accurately titled "The Twilight of MT for TPM". Though what they've really done is just move MT to a nursing home while keeping plugged-in to it's data. As I understand it, their treating everything as an "application" is just their way of saying they are treating all their local resources as web services providing a common API to it all (adaptors to things like MT). These are plugins/modules that have a common API (like a Markup* plugin in PW). For TPM's needs, having that extra layer of abstraction reduces their dependence on any one system. A desirable thing, especially when the main system (MT) is pretty ancient. So they've shifted their dependence from open source MT to their own system and presumably one or two coders. (incidentally, this is the opposite shift of dependence I would usually recommend). Those coders will now write adaptors rather than mucking about in MT. Those coders now have a proprietary system and secure jobs. I would hate having a job to fiddle with old-school MT all day, but clearly the management wasn't willing to kill off MT (otherwise I'm sure they would have long ago). So if this is the coders' answer for how to do more interesting work without killing off MT, then I applaud them for it. Getting down into the details, the intentions sound noble and well founded. But practically speaking, we're talking about more layers and more complexity. Perhaps that provides the right balance and level of comfort for their CM needs. But their needs are pretty specific, and to suggest this is the right approach for others I think is missing the mark. I suspect they would be better off if they'd just standardized on a more modern and capable platform (rather than an elderly blogging engine). Newer platforms would give them much of the perceived benefits of their approach and be far less costly and easier to maintain. With another modern CMS, they would accomplish the same thing but hopefully not have to develop everything themselves. This is where I started questioning the author. Apparently PHP is an "unwise" language. Yet it's powering many of the world's largest, highest-traffic sites (Facebook being an example). No other language can come even close to the scale and scope with which PHP has been successfully used on the web. Regardless of whether one likes PHP or not, it has gotten the job done at a scale not ever seen before. Given that track record, I believe that saying PHP is "unwise" is a statement that significantly lowers the credibility of the author. This statement has nothing to do with the "plugin model". It has everything to do with supply and demand. Their solution is to move their "plugin model" in-house. If they are paying to create their own plugins then they decide when to abandon them rather than someone else. Cool, but it's still economics. Perhaps that's how it works in MT (I don't know). But this is not how it works in WordPress, Drupal, ProcessWire or any quality open source CMS. The author is describing a patch system not a plugin system. If the plugins needed to know about each other it wouldn't be a very good plugin system would it? I don't think the author knows what they are talking about in this case. But if that's their definition of plugins, then apparently that's why they aren't calling their plugins "plugins". I think that a lot of good points are made in this article, but only towards reinforcing the direction that many modern frameworks and CMSs have already gone to. And they would probably be better served by investing their efforts into such systems. I do like their solution for adapting to their legacy systems, but this is hardly new. I enjoyed the article but am disappointed with the way they've presented the ideas as something they are most definitely not, i.e. "The Twilight of the CMS", "A New Hope", "The Baroque Road Ahead"... come on. Somebody's been using MT for far too long...

Thanks for your offer to help. I'd run off my own silly version control (and occasionally, lack of it) for many years, and then experimented with SVN for awhile, before finally making the jump to Git. Git has changed my workflow quite a bit, and I occasionally find myself in trouble, but I'm getting the hang of it. I'm not using multiple branches as much as I should due to some early missteps that made me risk averse. But hope to be a seasoned pro with Git by the time PW 2.2 is out.

I'm an idiot. I never read the subject line, just the message. I completely missed the part about the template name containing only numbers... time for me to get a cup of coffee and wake up.

As for how to use the TemplateFile class, you've got it exactly right. You can access everything you set() directly from the var name in the file, such as $headline and $body, etc. If you prefer it, you can also use the setArray() method (inherited from WireData) to do something like this (though I think I prefer the readability of your version): <?php echo $out->setArray(array( 'headline' => $page->get("headline|title"), 'body' => $page->body, 'sidebar' => $page->sidebar, 'navigation' => $pages->find("parent=/") ))->render(); TemplateFile is the class that PW uses to output your templates. I actually don't use it very often in my own sites. That's in part because I work mostly alone and don't have to compartmentalize stuff quite as much as if the work was split. I do think it makes sense to use TemplateFile more and more as the size of the team grows and you need templates with limited access and scope (as a good thing). The strategy that I use does not have limited access and scope, but it is probably more efficient and less verbose than using the TemplateFile class. Though it's also a similar approach in many ways too. The way it works is that all the site templates pull in the same main markup file (main.php). That main markup file is looking for values to be set to the $page object… whether those values were set in PW, or by some other template. Templates may also modify the values (usually appending or prepending) before sending to the main template. If an expected value is not set, then the main template supplies a default. So templates really only need to supply values for those things that they want to change. This is what that main.php markup file might look like: /site/templates/main.php <?php // set default values for topnav and subnav. // these aren't PW fields, so we're just using $page to hold values that other templates can override if(!$page->topnav) $page->topnav = $pages->get("/")->children(); if(!$page->subnav) $page->subnav = $page->children(); // we want all templates to have jquery, main.js and main.css $config->scripts->add('jquery.js'); $config->scripts->add('main.js'); $config->styles->add('main.css'); // if a JS or CSS file has the same name as the template, then use it if(is_file($config->paths->templates . "scripts/$template.js")) $config->scripts->add("$template.js"); if(is_file($config->paths->templates . "styles/$template.css")) $config->styles->add("$template.css"); // now output the markup ?> <!DOCTYPE html> <html lang="en"> <head> <title><?php echo $page->get("browser_title|headline|title"); ?></title> <?php foreach($config->scripts as $file) { echo "<script src='{$config->urls->templates}scripts/$file'></script>"; } foreach($config->styles as $file) { echo "<link rel='stylesheet' type='text/css' href='{$config->urls->templates}styles/$file' />"; } ?> </head> <body id='body_<?php echo $page->rootParent->name; /* for targeting in CSS */ ?>'> <div id='topnav'> <?php echo $page->topnav->render(); ?> </div> <div id='subnav'> <?php echo $page->subnav->render(); ?> </div> <div id='bodycopy'> <h1><?php echo $page->get('headline|title'); ?></h1> <?=$page->body?> </div> <div id='sidebar'> <?=$page->sidebar?> </div> </body> </html> Then all the other templates in the site customize the variables that get populated, and they pull in the main template. For instance, the homepage template: /site/templates/home.php <?php // we don't want subnav on homepage, so make it empty $page->subnav = new PageArray(); // list the 3 newest news items in the sidebar $page->sidebar = "<h2>Latest News</h2>" . $pages->find("parent=/news/, sort=-date, limit=3")->render(); // since it's the homepage, we'll add a masthead photo above the body if($page->photo) { $photo = $page->photo->size(600, 200); $page->body = "<img id='masthead_photo' src='{$photo->url}' alt='{$photo->description}' />" . $page->body; } // add a note about when it was last updated, just for kicks $page->body .= "<p>Last updated " . date('m/d/Y H:i:s', $page->modified) . " by {$page->modifiedUser}</p>"; // include the main template include("./main.php"); I also want to mention that main.php isn't actually used directly by any pages... I don't even keep it as a template in PW. Though you certainly could. But I just use main.php for inclusion by other templates. That's the approach I use most often anyway. What other approaches to people use?

Jose, I do have an upgrade utility written, and have used it on a couple of my own sites. Though don't feel it's been tested enough to recommend using it on other sites yet. So I recommend waiting on upgrading existing sites to 2.1 until the upgrade utility is considered stable. Though feel free to try it out for fun if you want to: https://github.com/ryancramerdesign/P21/blob/master/upgrade.php You would comment out the first line (with the die function on it) so that it can run. To upgrade you would remove or rename your old /wire/ dir and replace it with the /wire/ dir from PW 2.1. You would also replace your /index.php and /.htaccess files with the new versions. Then you would load upgrade.php in your browser. I have been busy working on client projects and PW 2.1 main source, so this upgrade util hasn't been touched for a few weeks, but will be in August. As for why it's put in P21 rather than as a branch of ProcessWire, that's due to me being a newbie with Git. I managed to screw things up pretty bad when trying to maintain a separate branch and eventually gave up and just put it in a separate repo. Most likely this will be bundled back into the main ProcessWire branch once it's final (assuming I can figure it out!)

Thanks for the report. I haven't seen this and I've been adding templates all week–developing 2 sites like a madman. Is there anything I need to do to duplicate this or browser I need to test in? I've been using mostly FF5 mostly and Chrome 12 a little less so. If you select that area and 'view source', do you see any obvious problems in the markup? I'm not seeing anything on mine, but of course this problem could be somewhere else and just affecting the table. I'll do some testing with a validator. But based on what you see, do you have any thoughts as to what the problem is? (markup error, javascript, etc.?)

Slkwrm, thanks – you are too kind. The commenting is good alright some spots, but needs a lot of work in others.

Regarding whether to use "===" or "==": if you are comparing Page object to object, you would want to use the "===" rather than "==". That tells PHP to check that they are in fact the same instance (i.e. occupying the same block of memory). There may be a slight performance benefit to using "===" to compare object-to-object rather than comparing ID because $page->id triggers some action in the class, where as "===" is likely handled all in PHP's core code (in C). Regardless, I prefer to compare the ID. It doesn't matter if you use "===" or "==" when comparing the ID. There is also a side benefit in comparing the ID because there is a possibility that you could have two instances of the same page in memory. PW tries to prevent this from happening by keeping a memory cache of everything that gets loaded. But if you have a $page in your code's scope and not in PW's scope (due to some action that clears PW's memory cache), and the page gets loaded again from a $pages->find (for example), then it's feasible you could have two instances of the same page... yours and PW's. In such a case, comparing $p === $page would return false, whereas $p->id == $page->id would return true. For this reason, I think it may be better to compare the ID. Actions that clear the cache are: saving or deleting pages. If your block of code doesn't do any page saving or deleting (or manual cache clearing)… or calling anything that does, then comparing object-to-object with "===" is a fine way to go. But if you don't want to have to think about such things, then maybe better to just compare the IDs.

If I understand correctly, I think this is what you are looking for: http://processwire.com/talk/index.php/topic,128.msg790.html#msg790 Based on what you've indicated, you'll want to change two things: 1. Currently it's applying the class "on_page" or "on_parent" to the <a> tag rather than the <li> tag. You mentioned you want it on the <li> tag, so you'd move the $class variable from the <a> tag to the <li> tag (which is just 3 characters before it). 2. Since you want the class name to be "current", you'd replace the "on_page" and "on_parent" class names hard coded in there to be "current".

I'm thinking maybe we should have built-in date formatting for the 'created' and 'modified' fields. What do you guys think, maybe an alternate syntax for accessing the formatted version? Like $page->dateCreated is the formatted version of $page->created? It would just be formatted by whatever is set to $config->dateFormat.

That's correct that the ID should be in the address bar, visible in the URL (at least, that's where I get it). We also used to have the ID displayed in the interface in the far right corner, but the new Save button is now covering that ID. Perhaps we should find another location to put the ID back in. Good question about whether to use the ID or the path. Here are some points on that: Using the path is better for clarity in your API calls. I rarely use the ID for API calls (too much work). If the page is going to move at some point (or it better suits your style), you are right that using the ID is preferable because no on-site links will be broken. There can be a slight speed advantage to using the ID over the path, but at a loss of readability. Moving pages in your nav breaks off-site links regardless. Better not to move main pages after launch. If all you are getting from the page is the URL, and you are building non-dynamic nav, consider just hard coding it (for the most efficiency). Don't load extra pages if you don't have to. Accounting for pages moving is the only reason I would use IDs in the example you posted. And that's a perfectly good reason to do it. But that particular example wouldn't translate well to using paths because it would be redundant: <a href='<?=$pages->get('/faq/')->url?>'>FAQ</a> <a href='<?=$pages->get('/about/contact/')->url?>'>Contact</a> The above is redundant and unnecessary, because you could just do this, which is much more efficient (no API calls necessary): <a href='/faq/'>FAQ</a> <a href='/about/contact/'>Contact</a> I run my dev sites off subdirectories and need them to be compatible between dev and live. So I reference the root URL in my sites when coding static navigation. But this is just as efficient as the example above. <a href='<?=$config->urls->root?>faq/'>FAQ</a> <a href='<?=$config->urls->root?>about/contact/'>Contact</a>