teppo

Thanks! There was an issue in PageSnapshot.module preventing it from working properly unless FieldtypeRepeater was installed too. I've just pushed fix for that to GitHub, so if you could fetch latest version and see if it works any better?

Not really a ProcessWire wish, but related: Currently it's only possible to state a supported ProcessWire version for a module in the modules directory, and that has to be 2.0, 2.1, 2.2, 2.3 or 2.4. Anything beyond that has to go to comments (where it's rather easy to miss). The most basic thing I could think of would be the ability to provide required ProcessWire version as '2.4.1' etc. in case that nearest minor version (2.4 in this case) isn't supported. I'd also like to specify any other modules that are required -- and perhaps even more specific things than that, such as PHP version or specific extension (Imagick comes to mind first).

@sid: sounds kind of like you could have an earlier version of Page Snapshot module installed. Could please you check that you're running version 1.1.18 of it? I'm sorry for the confusion about supported ProcessWire version. Dev branch is really needed to run this module. My original post mentioned that the module requires "2.4.1 or later, i.e. current dev branch", but since modules directory doesn't allow submissions unless you define a version ranging from 2.0 to 2.4 as compatible.. well, I can see how that could happen.

If you just need to remove those specific parts (i.e. all URLs start with index.php/news/11-latest-news/) then try this: RewriteRule ^index.php/news/11-latest-news/(?:[0-9]*-)([^\/\.]*).html$ http://www.domain.com/news/latest-news/$1/ [L,R=301] If that's just one example and you're looking to remove index.php and all sequences of [0-9]*- from beginning of pages, you might have to do something like this instead: RewriteRule ^index.php/(?:[0-9]*-)?([^\/\.]*)/(?:[0-9]*-)?([^\/\.]*).html$ http://www.domain.com/$1/$2/ [L,R=301] RewriteRule ^index.php/(?:[0-9]*-)?([^\/\.]*)/(?:[0-9]*-)?([^\/\.]*)/(?:[0-9]*-)?([^\/\.]*).html$ http://www.domain.com/$1/$2/$3/ [L,R=301] Note: that last one is pretty ugly and requires new rewriterule for each level of content. I'm not aware of any sensible way of implementing string replacement via rewriterules, so if this really is the case you might benefit from actually doing this with PHP -- just point all index.php requests to custom PHP script (or page or whatever) and do 301 redirect from there after a bit of preg_replace() magic.

@muzzer: markup cache is definitely a great tool if you've got otherwise highly dynamic pages that can't be cached as a whole. If, on the other hand, the page stays pretty much same on each page load, I'd suggest looking more into template level caching -- that way you'll have entire page cached instead of caching separate regions and then combining those on the fly. If you're really interested in speeding up your sites, ProCache is the ultimate solution. For the most part it'll be serving static pages without involving PHP or MySQL at all, which will always beat the speed of any page built on the fly (regardless of what CMS is used). Just saying.

What Ryan and Antti are saying here definitely makes sense (and they're the ones to know the module best anyway) but this was exactly what we were wondering too when that first Lister screencast hit our office. For 90% or more of all product, news, event etc. lists and/or tables Lister views would be more than enough. No custom, site-specific code and even being able to allow customer decide exactly what is visible and where.. and then modify that whenever needed -- how damn cool would that be? In case you ever decide to take Lister to that direction, it'd be a killer feature for a lot of sites (and an awesome time-saver for people building those sites), but I totally understand that this was never your intention and it would probably require a ton of extra work. Perhaps even so much that building another tool just for that would make more sense. Still, +1 for this idea from me/us

While testing I had mostly similar results to those of Soma for the basic site profile out-of-the-box (on localhost), but some actual production sites took a bit longer to load -- around 200-300ms. If we really wanted some comparable results, we'd need all the details of aforementioned tests (including a test site to run those tests on on) just to rule out different measuring methods and side-effects of installed modules

Umm.. probably a stupid question, but in your picture ProcessWire startup time looks more like 0.6ms than 600ms. Which doesn't seem that bad. Am I reading this wrong?

Sorry if I'm making this even more confusing, but it's really not that difficult, once you grasp the general concept: Consider all data coming from the user dirty. In PW anything that comes from $input. It has to be sanitised and it's always better to be too strict than too lenient about it; don't worry about being overly cautious, that very rarely causes any issues while not being cautious enough.. well, that's another story entirely. Also, there's no such thing as "general sanitizing". It depends on what kind of values are valid in this specific use case. If possible, compare to an array of valid values, but if/when that's not feasible ... if you only want integers, typecast value to int first: $value = (int) $input->post->value; if you only want plain text, use $sanitizer->text(): $value = $sanitizer->text($input->post->value); if a sanitizer feature matching your use case exists, use that; if you want to check for valid page names, use $sanitizer->pageName(), and if you want to check for valid emails then use $sanitizer->email() etc. if you're inserting user data in HTML, make sure it doesn't contain anything that could break the markup: <input type="text" value="<?php echo $sanitizer->entities($input->get->value); ?>" /> to convert all applicable characters to entities (such as " => ") or at least <input type="text" value="<?php echo str_replace('"', '', $input->get->value); ?> /> to remove double quotes, which would obviously cause problems here etc. If you're still worried that you don't know enough of this, try Google; there's a lot of various tutorials about the subjects of validating, filtering, escaping and encoding data (the terms are related but have slightly different meanings, by the way). This Smashing Magazine article, for an example, explains the basics pretty well. Another resource I'd highly recommend is SlideShare presentation from Chris Shiflett, "Evolution of Web Security". The scope of this is much wider than just sanitizing user data, but that's all stuff that any decent web developers should be aware of anyway, so it definitely won't hurt you

Hear me out, guys! Based on extensive user surveys and after tremendous amounts of solo brainstorming (and other other proven methods, such as wearing all of the six thinking hats simultaneously) I've just come up with a new marketing strategy (and slogan) that will most definitely make us unbeatable: How's that for a slice of fried gold? .. and on a more serious note, I've also got tremendous amounts of respect for Kongondo and his work here. Never visited MODx boards and still don't know what the heck Wayfinder is, but he's done some pretty awesome stuff here too In my case it was Antti who threatened to break my legs brought ProcessWire to the company we both worked at back then. Ryan's video was my first contact with the system itself and the thing that really convinced me that Antti wasn't just delirious -- this thing actually looked great!

@yellowled: that sounds just about right. ProcessWire uses Blowfish algorithm for passwords whenever possible (PHP 5.3.0 onwards) and a stronger version of it if PHP version is 5.3.7 or newer. Passwords created in earlier versions will get the update notice and there's at least a chance of problems arising if you go from PHP 5.3.0-5.3.6 to 5.3.7 or newer -- or vice versa. If I'm reading you correctly and the same site can be accessed with multiple PHP versions, I'd assume there being quite a bit of weirdness. That's a problematic situation in many ways, and this is just one of those

Couldn't find a really clean way to do this at the moment, but since the view used in pwlink TinyMCE plugin is essentially ProcessPageEditLink and it's execute() method is hookable, you could try tapping into that and altering the resulting markup (return value of said method). This is first request I've seen for such a thing, but if this sounds like something that would make sense in more cases I'd suggest asking Ryan (by creating a GitHub issue for it) if adding a better way to do this, i.e. new hookable method somewhere before the form markup is generated, would be possible. Edit: almost forgot: welcome to the forum!

There's a bit of difference between operators "*=" and "%=". Quoting from the documentation: In many cases %= is more "forgiving" and generally just finds more results than *=, so I'd try if that helps. It might also make more sense to search by name, which is often identical to title, just all lowercase characters and spaces etc. converted to dashes: // find with name and use %= (SQL LIKE oeprator): $english = $pages->get("template=language, name%=english"); // alternative approach if you know that there's "english" at the *beginning* of the name: $english = $pages->get("template=language, name^=english");

Well, you could always use has(). Depending on what these pages really are etc. try something like this: $english = $pages->get("template=language, title=English"); if ($page->DMC_select->DMCstats_Language->has($english)) { // do stuff }

@Macrura: you're welcome @owzim: didn't realise that core already takes care of this, so it should pretty much work out of the box. At least that's true for Fieldtype Map Marker and repeaters (just tested). For the record, there's now some very basic output formatting (CSV, basically) for array type values built-in. The need for this came up while outputting values from repeaters, i.e. "here's a list of my friends: {{friends.name }}" (which should now output something like "here's a list of my friends: Smith, Johnson, Williams, Jones").