ryan

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.

Yes that's the one. This is probably the best one in terms of consistency with the current look/feel. The only issue is (as discussed in that thread) that the Mahalia 'w' placed next to the Avenir reads like "PU"... that's my fault for choosing these typefaces for the logo. And one reason why we'll eventually get a new logo design. Though I'm not sure how big of an issue it really is, but I just have trouble unseeing it. That's really the only reason I swapped the typefaces for the P and the W in the experiments.

I don't have access to a Windows machine at the moment, so was kind of limited on tools. Found a couple others, but they couldn't handle the file size. I tried a few more browser plugins and found one that worked nicely. A Chrome extension called XV seems to do alright with the XML file. It does take about 5 or so minutes to load this large XML file, but once loaded, it works pretty well as an XML browser. I'm feeling lucky--PHP's simplexml loads the file in about 5 seconds and has no problem parsing it. Somebody must have done something right with PHP's simplexml.

That is the one rule that you cannot do without. Try uncommenting this rule in the .htaccess file: RewriteBase / If you are running from a subdirectory off your hostname, then add that subdirectory to it. If you still get a 500 error, try commenting the line that you mentioned, and then uncommenting the alternative one a few lines below it, where it says this: # ----------------------------------------------------------------------------------------------- # If using VirtualDocumentRoot: comment out the one above and use this one instead. # ----------------------------------------------------------------------------------------------- # RewriteRule ^(.*)$ /index.php?it=$1 [L,QSA] If you still get a 500 error after all that, chances are your web host has either broken or limited access to Apache's rewrite engine, and you'd probably need to talk to them about fixing it. Please let us know what you find.

I'd like to go ahead and finalize ProcessWire 2.3 (aka 2.2.13) and get it out there as our main download next week. I think many of us have been using it for months and any major bugs have been worked out. There is always a list of things to do, but I think it would be especially good for new installations to start from 2.3. It makes sense to retire 2.2 which has several [minor] bugs in it that have since been fixed. If anyone has extra time over the next few days, would you mind attempting a fresh install of our 2.3 release candidate (aka 2.2.13) and letting us know how it goes? It is available for download here: https://github.com/ryancramerdesign/ProcessWire/tree/dev I'm particularly interested to know how the new install process goes for people, as there have been several changes to the installer. We also need people willing to upgrade their 2.2 installs to 2.3 to make sure it goes smoothly. Upgrade your own site, but don't yet upgrade your client's mission critical site until we've received confirmation from others that all went well. Here is the upgrade process: 1. Replace your current /wire/ directory, in it's entirety, with the new one. You probably want to backup the old one and replace it completely. I do this by renaming my old directory to something like /wire.old/, and then putting in the new one. If you do that, just remember to delete the /wire.old/ once you don't need it anymore, as it would be a security problem to leave it there. Do not FTP, SCP or RSYNC directly into your existing /wire/ directory because that will result in a monster of old and new files (since some file locations have changed). 2. Replace your existing /index.php with the new one. 3. Replace your existing /.htaccess file with the new one. The new one comes named htaccess.txt, so you'll have to rename it to .htaccess. If you had any custom rules setup in your old htaccess file, remember to copy them to your new one. 4. Load a page from your website in your browser. You will most likely get a Unable to complete this request error. Hit reload and it should be gone. If not, then remove these files and try again: rm /site/assets/cache/Modules.* If it still doesn't work, then look at the last entry in /site/assets/logs/errors.txt and post what it says. 5. Browse your site and make sure everything is working how you expect. Login to the admin and do the same. Please report your experience here. 6. Have a beer. Thanks, Ryan

Were you able to complete the install before the 500 started occurring? If so, did you get any error messages, particularly during the compatibility check? I'm assuming this is an Apache 500 error, and not a ProcessWire 500 "Unable to complete this request due to an error" message. To me it sounds like something specified in the .htaccess is disallowed by the host. The best way to troubleshoot is probably start commenting stuff out in there by placing a '#' in front of each line, testing one at a time.

Here are all of my experiments, which are a little larger (after you click on them), but not much. There was also another thread here that had some nice examples from Diogo, Mademyday and others, but I can't seem to find it.

Thanks for this module Adam! What most people don't know is that Adam doesn't just write in Markdown, but also speaks in Markdown.

Great work niutech! Thanks for putting this together. This seems like a really nice implementation you've put together here that plugs in effortlessly. In addition to being a great solution for those that want to use Smarty, it's also a great example of how one can implement a template engine with ProcessWire. Excellent readme too. One suggestion, related to what Soma said. Though this is minor. Your repo has a /wire/modules/ directory, and you might want to move /modules/ to your /site-default/ directory. Ultimately you can run a module from /wire/modules/ but it'll get wiped out every time you upgrade. So it's just a lot safer to keep them in /site/modules/, which gets retained through upgrades. Since people often skim through a readme, they might use your /wire/ dir as a guide rather than the readme. While less important, it might also be better to use /site/ rather than /site-default/, since /site-default/ is just a dir that would be present on an uninstalled copy of PW. Please add this to the modules directory at your convenience: http://modules.processwire.com/add/

Also check to see if there is any error message in /site/assets/logs/errors.txt

Also make sure that you've got a /site/install/files/ dir in your profile, even if it's empty. I'll remove this dependency from install.php soon though.

There isn't. But that's not really an official logo either. It was just a photoshop experiment. I liked it, but nobody else did, so you don't see it on the main site.

How much data are you talking about? What kind of queries would you be performing on the data? The vast majority of things you can do from ProcessWire's API, but we also don't try to cover the entire scope of MySQL either. So I'd be curious to know what kind of statistics you are pulling out of the database currently, before recommending whether you should use pages for the purpose. You could absolutely do this. Creating a custom admin section is as simple as: a) creating a new template, then creating a new page in admin that uses that template; or b) creating a new Process module, then assigning it to a new page in admin (that uses template 'admin'). The admin itself is nothing more than a web app created in ProcessWire… you can extend it in the same way you would your own site.

You can do this. Whether you choose to go the direction of user accounts and admin access is another question. For modules.processwire.com people can submit modules to the directory. When they submit a module, they also enter their email and password. That info gets saved with the module, so that anytime they want to come back and make edits, they can. I'm not using user accounts for this because my needs here were pretty simple. This method also requires using the API to code it to do exactly what you need... but it's not difficult. You can also use user accounts (and even admin access) if you want to. Though I recommend limiting admin access (even limited admin access) to trusted users. With trusted users, the Page Edit Per User module opens up many possibilities here.

Currently there isn't a way (that I know of) to have different user types. Meaning, whatever fields you add to your 'user' template are going to be present for all users. However, you could always create other templates with whatever fields you need, and then relate them to the users via Page references. You could also use tabs or collapsed fieldsets to hide sections that aren't applicable to all users. In terms of navigating in the admin: ProcessWire admin is nothing more than a website written in ProcessWire. If you think of it that way, you can swap out of any of it's components (Process modules) or make your own templates that display exactly what you need. You can add a new page in the admin just as easily as you can add a new page on the front-end of your site.

Nice update, thanks Nik. This module puts a smile on my face every time I use it.