ryan

I'm not sure exactly what changes might be necessary to make it work with nginx, but I have no doubt that if you are able to get ProcessWire safely working under nginx, then ProCache should work fine too. However, you may want to remove write access to your .htaccess file so that ProCache can't write to it. That way you are implementing any updates manually (and adjusting them for nginx). I'm curious to know if the ProCache rules work under nginx as they are, or if you have to make any specific changes?

Soma, once we've got 2.3 as the current stable version out there, I'll go through the cheatsheet and figure out what needs to be added, etc.

Thanks for finding that Nik. I've tried to find a simple fix, but no luck so far. It seems that I break a lot of the other tests with nearly any solution I implement, so far. So going to need to find time to get further into this soon. Do you have one of these in the tests?

Looks like the University of Oregon cheerleaders/dance team have made excellent use of the Blog profile: http://uodance.com/

Looks to me like the logo is a little too wide for your mobile version. You could solve it by just making a more narrow logo as the default, so that it fits on mobile. Or you could use media queries in the CSS (see the example files) to display the logo at a different size when at mobile portrait. A quick-n-dirty fix might be to add an inline style to the the <img> tag, i.e. <img style='max-width: 100%;' ... />

WillyC's example actually works. Returns the 10 last updated files. But the shell commands it executes are pretty unix specific (though am guessing there is an equivalent in Windows). We might be able to just add a timestamp field to the file-based fieldtypes too. I kind of hate to duplicate info like that, but the reality is that disk space is cheap and making them queryable from the PW API would be nice.

This is what I usually do. A few things I've occasionally had to take into account when doing this, in addition to the image path you mentioned: The installer never gets to run, so doesn't have the chance to confirm compatibility with the server. If it's a new server you haven't used before, you might try just installing a test copy of PW to see if the installer mentions any issues. I usually do that if something doesn't work after copying the site over. You need to make sure that permissions are retained for /site/assets/. Sometimes I have to reset the permissions after copying to the server so that everything is still writable. If using a cache, you might want to clear it before or after copying to the server: rm -r /site/assets/cache/* Most of the time, I don't have to do any of these. But it's good to know about them for when you do.

But then how to get the dynamic description into the static HTML from TinyMCE? It would have to be done at runtime with some kind of variable replacement. That's something I've been trying to avoid with TinyMCE, though don't have good enough reasons. One of my problems with the default dialogs in TinyMCE (and most other editors, for that matter) is that they present every possible option and only a developer would understand the vast majority of them. For instance, the distinction between a description and a title is going to confuse the non web-developers. I tend to think we should just make the behavior a checkbox in the module's configuration rather than the image editor. Another thing to consider is that we'd be duplicating an 'alt' to a 'title' for the benefit of javascript. When faced with that, it's technically more efficient to duplicate the attribute in javascript rather than in the markup, i.e. $(document).ready(function() { $(".gallery a > img").each(function() { // copy image 'alt' attribute to a 'title' attribute $(this).parent('a').attr('title', $(this).attr('alt')); } }); Do you mean add attributes? Not possible at present, just because our JS-side of things needs to know what the attributes are ahead of time (though some re-coding could solve that). But since these tags only accept a limited number of attributes anyway, I'm not sure we need that scalability here.

Antti, what are the table features that you find to be better in CKEditor? I was playing around with the demo on their site, but couldn't figure out how it was better in that regard (though I didn't experiment for long).

On the details tab, what do you have for "number of decimal digits to round to"? On the input tab, what do you have for "numeric input type?"

I'm confused -- I haven't changed anything here, and the getDatabaseSchema() function for FieldtypeFloat still says this: public function getDatabaseSchema(Field $field) { $schema = parent::getDatabaseSchema($field); $schema['data'] = 'float NOT NULL'; return $schema; } Can you clarify what you mean about them being stored as ints in the DB? I want to make sure I didn't break something.

I plan to upgrade the image and link dialogs to account for more attributes. Definitely a class attribute, though hadn't considered a title attribute (wouldn't that go on a <a> tag instead?). As for making alt an optional attribute, that's not planned because it's required by XHTML (even if it's blank).

What are some other editors you've seen that seem good? I've not kept up with these so well and am wondering if there are any standouts right now. Of course redactor looked great, but not something that can be bundled in a GNU open source software.

I've switched back and forth between checkboxes and autocomplete, but so far can't duplicate the issue you were running into there. I wasn't able to duplicate the issue with german umlauts (they are matching well here). However, I did have trouble once I started using a concat field as the "label" field. For some reason, that doesn't not seem to work at all with the autocomplete. I'll take a closer look at this and see what's up there. But try changing your label field to 'title' or something else and see if that fixes the issues you were getting? You might also try changing your autocomplete search operator to '%=' as that will match text with fewer than 4 characters, as well as more partials.

I do have access to a windows VM, that I use for browser testing. But that is running WinXP + IE and space for nothing more. It's also very slow (probably because it's a VM), definitely not the environment I'd use to process a large XML file. I've got nothing against PCs, and I've enjoyed them for most of my life. I didn't care for Macs until OS X came into the picture. I'm one of those guys that wanted to be running on *nix and needed Photoshop, so OS X was the only game in town. Now it's been years since I've used a PC, and I just don't encounter them around here that much.

niutech, if you want to clear the cache after save like Wanze mentioned, you could do it like this: public function init() { $this->pages->addHookAfter('save', $this, 'clearCache'); $this->pages->addHookAfter('saveField', $this, 'clearCache'); // optional } public function clearCache(HookEvent $e) { $page = $e->arguments[0]; // if you need it // clear cache }

This might be a dumb question, but... couldn't you just overlap? Pull the last 30 minutes, even if you only need 15. And then skip over any you've already processed?

Are you running MAMP or something like that? If so, /usr/bin/php is not your PHP (at least, not the one you want). You probably want your script pointing to something like: /Applications/MAMP/bin/php/php5.3.6/bin/php (depending on what PHP version you have)

Thanks for the testing JeffS. Glad to hear all is going smoothly so far. I would open a new thread... but don't really know how to do that and move these messages there. If I figure it out, I'll do it. I like staying on top of the latest jQuery, but the reality is they are prone to changing their API and breaking things in every major version. I think it's better to let those versions marinate for awhile in a dev branch before making them part of stable. So I'll update to 1.9 in the dev branch once we get 2.3 out there.

If dealing with potential large quantities of pages, a fairly efficient way to check if the page has visible children: if($page->child->id) { // page has children } else { // page has no children // or you are paginating and none are left } If you are going to be using $page->children either way, then it's better just to use it the way you are though. If pagination is involved (whether with the children or something else), then it's better to $page->children->getTotal(); to eliminate the possibility of count() returning 0 due to being at the end of a pagination set.

For that field, what are your settings for: 1) selectable pages 2) label field 3) autocomplete advanced options (post a screenshot if that's easiest) Also, what version of ProcessWire?

While the result was different, we did see an odd issue once when someone FTP'd ProcessWire to the server in ASCII (rather than Binary) mode. So that would be another thing to double check, that the files FTP'd in binary mode.

Thanks for the follow up on this. I don't think it's magic quotes, just because PW's $input API variable is abstracted from the magic quotes setting (meaning, that setting shouldn't matter). Though if it was somehow doing double magic quotes, that might be an issue.

Thanks for finding this. I've updated it so that it now includes hidden. I'm still debating whether this shouldn't instead be: "include=hidden, check_access=0" or even "include=all".

Not sure what all this entails in terms of tangible things, but I'd love to see this.