ryan

Nik, thanks for your research and testing on this. Admittedly I found a lot of ambiguity about the the salt rules. It's been awhile now, but if I recall correctly I was not getting the expected results when taking the PHP docs literally on this one. I found several other sources that indicated it should be 21 characters plus a trailing $, so that's what I went with. My first inclination here is to avoid the issue you brought up by making supportsBlowfish() return false when the PHP version is older than 5.3.7. After all, 5.3.19 and 5.4.9 are the current, so treating 5.3.6 and lower like 5.2 probably makes sense here. Based on your understanding of this, would this solve the issue you were running into? Or do you think revisiting the salt length is a necessity?

If you are using any template or markup caching features, you might also want to clear those caches after moving a site to/from a subdir. To do this, go in the admin to: Modules > Markup > Markup Cache > clear cache Modules > Page > Page Render > clear cache

Those status values are just meant to indicate the comment's moderation status whether spam, pending or approved. They aren't bitmask flags like a Page status, so I don't think it's a good candidate for what you are trying to do unless your statuses would supersede the built-in ones. You might instead want to designate a certain email address or IP address to indicate a system comment. These fields are already built-in and can potentially be repurposed. You can modify any of the values before a comment is saved by hooking before one of the functions in FieldtypeComments.module. I would recommend either sleepValue or savePageField, both of which are called before a comment is saved. Another alternative is to copy and rename the FieldtypeComments.module or all of the comment module files to make your own customized comments module. If you go that route, you'll need to rename the classes. I know that Nico has done this, so you may want to look at what he's done with it as well.

Just to confirm, this is the line that doesn't work? foreach($products->find("applications=$a, uses=$u")) as $p) { I can't say for certain why not because I don't have the code in front of me to execute, but make sure you were using $products and not $pages. If you want to test an alternate, it could also be written as this: foreach($products as $p) { if(!$p->applications->has($a)) continue; if(!$p->sectors->has($s)) continue; echo "<li><a href='$p->url'>$p->title</a></li>"; }

Cropping direction has been added to the latest commit on the dev branch. Example of usage: $image = $page->image->size(300, 200, array('cropping' => 'north')); // or you can use this shorter syntax $image = $page->image->size(300, 200, 'north'); That would make it crop towards the top of the image. Possible values for crop direction include: northwest, north, northeast, west, center, east, southwest, south, southeast or a blank string to disable. If you prefer, you can use short versions like 'nw' for northwest or 's' for south, etc. Crop direction can also be used with the width/height functions: $image = $page->image->width(300, 'north'); PW now supports this shorter syntax for crop direction, and also with quality and upscaling. If you specify a string for the last argument, it assumes you are specifying a crop direction. If you specify an integer, it assumes you mean a 'quality' setting. If you specify a boolean, it assumes you mean an 'upscaling' toggle on/off. If you need to combine multiple options then of course you should specify an array, as before. This behavior applies to the size(), width() and height() functions. If interested, more details are in the function comments. Thanks to interrobang for providing the implementation of crop directions.

The profile exporter does exist, but I don't think it has seen a lot of action yet. I hope to change that and put out a couple more profiles myself here soon.

Arjen thanks for creating and sharing this module. Can you post to the modules directory?

This thread was started for a different trip, but figured I'd re-use it since it was already here. I'm back in town finally after a great vacation. Thanks to everyone for keeping things running smoothly here. It looks like it's been an exciting week here with all that's going on with the Wiki and some cool releases. I look forward to getting caught up! Today I'm just unpacking and such, but will be back in the forum and email tomorrow. It may take me a few days to get fully caught up. To people that have posted messages directed at me or emailed me, thanks for your patience. I will be sure to get caught up on every thread and email.

Thanks Soma this is really nice of you. Thank you also for all the great work that you are doing here! Now I have to logoff for a few days, so this is a great last post to read before I head out. Hope that you all have a great weekend and week! Also please no more Ektron licenses on my credit card.

I think you are better off not exiting, just because any hooks that go after render theoretically wouldn't get executed. It's possible some other housekeeping might get missed. Doing a "return;" might be better.

ProcessWire has a class called WireUpload that's worth checking out.

Definitely possible, and there are some past posts that cover similar territory (though can be admittedly hard to find). My office is just about to close up, so have to reply quickly, but here's a few places to start: Have a look at the API cheatsheet and the $pages var. If you want something ready-to-go, Form Builder can do this without you having to code anything. You might also look at the FormTemplateProcessor module at modules.processwire.com.

Could certainly do that. Not sure I'd want to make such long filenames full of MD5 hashes though. I suppose I'd prefer to have a human-readable filename that isn't quite so long. Though the scalable benefits of the hash are hard to argue with. Definitely something to think about.

Isn't Solr Java-based and have something to do with Lucene? I don't know if I've actually come across a server with this, though could be wrong. It seems perhaps a bit specialized for our case, but willing to look into it.

You'd want to hook after $pages->save(); If you want your function to execute on every page save, any time, then you'd want to create an autoload module. http://wiki.processwire.com/index.php/Module_Creation If you want to capture newly added pages separately, then you'd also want to hook $pages->added(), which is called after a new page has been added. This example shows both: /site/modules/HelloWorld.module class HelloWorld extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Hello World', 'summary' => 'Just an example module class.', 'version' => 1 'autoload' => true, ); } public function init() { $this->pages->addHookAfter('save', $this, 'hookSave'); $this->pages->addHookAfter('added', $this, 'hookAdded'); } public function hookSave(HookEvent $event) { // this function called any time a page is saved (whether new or not) $page = $event->object; // now you can access anything from the $page } public function hookAdded(HookEvent $event) { // this function only called after a new page added $page = $event->object; } }

Haven't tested, but adding this, or something like it, to your .htaccess (after RewriteEngine On) might work: # skip over URLs with a period (possible filename) or your admin URL RewriteCond %{REQUEST_URI} !(\.|processwire) # skip over requests to files that physically exist RewriteCond %{REQUEST_FILENAME} !-f # redirect to the same URL with a trailing slash RewriteRule ^(.*)([^/])$ http://%{HTTP_HOST}/$1$2/ [L,R=301]

The best way to debug cookies is to watch them in your browser inspector. In Chrome thats View > Developer Tools > Resources > Cookies. In Firefox, FireBug makes it easily to track them as well. Locate the cookie and then keep your eye on the window and watch what changes it goes through as you navigate between pages. Another thing to double check is that you don't have any output occurring before your setcookie(). That could very well prevent the cookie from being set. Even a little PHP notice that you didn't know was there could screw it up. So view the source on your page and see if you've got any error messages appearing above your <doctype>.

That setMaxFileSize is only in the dev branch.

I'd welcome the opportunity to do anything that helps move the ProcessWire project forward. I'm cool with interviews so long as I've got at least a rough list of questions ahead of time. I tend to think a lot before I speak so wouldn't want to waste people's time with "Hmm, let me think about that" or "Hmm, let me look up what FLOSS and FOSS means again." Since I don't work in an office with other developers, it's rare that I talk to anyone about webdev topics. But think I can do a good job when prepared.

All the users permissions should be now be fixed. Sorry, I didn't realize before I'd broken that.

It probably does make sense for us to go ahead and expand the file naming format to account for more variation beyond dimensions, and introduce it with the new crop positions. This will mean a few more considerations in the updates, but seems worthwhile.

Looks like you got it. The reason the first one didn't work is because $event->categories was a Page rather than a PageArray. So you were cycling the pages fields rather than categories.

I output a sitemap view of products and their application/uses I think that looks good. You may want to move your $pages->get("/usi/")->children call outside of the foreach loops so that you've got that cached for reuse: $uses = $pages->get("/use/")->children; Technically ProcessWire is caching it for you either way, so it's not absolutely necessary. But it's a good practice since some actions (like saving a page) can clear the memory cache. Though wouldn't matter in this code segment. Another alternate way would be to pre-cache all the products so that all the filtering is done in memory rather than by the database (potentially faster). Though the method you are already using is more scalable, should things grow to the point where you need to paginate. $products = $pages->find("template=product, sort=title"); $uses = $pages->get("/usi/")->children; $applications = $pages->get("/applicazioni/")->children; echo "<ul>"; foreach($applications as $a) { echo "<li><a href='$a->url'>$a->title</a><ul>"; foreach($uses as $u) { echo "<li><a href='$u->url'>$u->title</a><ul>"; foreach($products->find("applications=$a, uses=$u")) as $p) { echo "<li><a href='$p->url'>$p->title</a></li>"; } echo "</ul></li>"; } echo "</ul></li>"; } echo "</ul>";

You could also do it like below. I'm thinking you'd want to sort by 'title' or 'date' rather than by 'url'? $related = $page->yourpagefield->import($pages->find("yourpagefield=$page"))->sort("title"); if(count($related)) { echo "<h2>Related</h2>"; foreach($related as $item) echo "<li><a href='$item->url'>$item->title</a></li>"; }

I think this depends what sorting is used on the comments.