ryan

Looks like getlocalization supports JSON and transifex supports YAML. It would be fairly easy to convert to/from formats they recognize.

When you get into sending POST data, ProcessWire has an http class that you can use rather than something like CURL. The benefit of using PW's WireHttp class is that it will fallback to sockets if it has to, ensuring the class works just about everywhere. Here's an example of the same web service we outlined above, except that this one posts to it: $data = array( 'username' => 'ryan', 'pass' => 'mypass', 'email' => 'info@grab.pw' ); $http = new WireHttp(); $result = $http->post('http://www.domain.com/path/to/service/', $data); if($result) { $result = json_decode($result, true); if($result['status'] == 'success') echo "Success! $result[message]"; else echo "Error! $result[message]"; } else { echo "error posting data"; } As a side note, this service is using the same password for the user to add, and the web service password. In reality, you'd probably want those to be different things.

I'm assuming those $page variables were actually supposed to be $pages? That first set of functions you called in your example have no sort defined. if you don't specify a "sort" in your selector to these functions, the order is either undefined, or by relevance. Functions where sort is inclusive are family functions connected with a page, like $page->children(), $page->child(), $page->siblings(), etc. You can expect those to use a predictable order. But a $pages->find() or $pages->get() with no "sort=" in it means you can't expect any particular order. Except when you are trying to partial match a string, it would attempt to sort them by relevance. If someone had a selector like yours, I would guess they probably wanted this instead: echo $pages->get('/')->children("include=hidden"); // all // or echo $pages->get('/')->child("include=hidden"); // first

I'm a little confused by how the whole thing works, despite reading the code a couple times. But if it works, then seems like it should be fine. The only thing I'd worry about here is scale, as you have potentially numerous find operations going on in these loops. But if you don't need it to scale too large, then it may not be an issue. Since I'm confused by the code itself, let's step back and go to the original question: Another option here would be to go ahead and implement a template file for your 'person' pages, and just let your search connect with the output of those pages. If you didn't want to go that route, you could always just make your search output loop handle pages using template 'person' differently: if($m->template == 'person') { foreach($m->categories as $c) { echo "<li><a href='$c->url'>$c->title</a></li>"; } } else { echo "<li><a href='$m->url'>$m->title</a></li>"; }

Thanks for letting us know. That's cheap enough to make me jump. Already had a namecheap account, so went ahead and registered a few that were still available: runs.pw (maybe a sites directory?) grab.pw (fwd to the github maybe?) mods.pw (fwd for the modules dir) processwire.pw (why not) skyscrapers.pw (for the demo site) skyscraper.pw (for the demo site) wires.pw (who knows?) Anyone else find or buy any good ones?

Glad to hear this. We have so many here that are part of the MODX community too that it seems like a family, and I really want to see MODX do well.

That's correct. When PW 2.4 is here, it won't matter, because PW will require PHP 5.3+ as well. But this could be a recurring issue with PHP 5.4, 5.5, etc. I recommend that any modules available on the modules directory be required to have the same PHP version requirements as the version of PW they are written for. An autoload module that requires PHP 5.3 when they only have PHP 5.2 could take down someone's site.

My mind doesn't seem to understand pseudocode so well, but seems like you are on the right track. For something like this you'll want to test it all out to confirm it works the way you want to. Nobody can say for sure it'll work the way you want until it's confirmed to.

The PW API is always the same regardless of context. One of strengths of PW is in it's flexibility when it comes to sending or receiving web service data, and this is one of the things I use it for quite a lot. But you do have to tell it what to do, rather than it telling you what to do. At the simplest level, you could validate against an IP and/or password for authenticating the request. That may or may not be adequate, depending on who/what you are dealing with. In either case, use POST rather than GET. Here is a simple web service that adds a new user (written in the browser / not tested). This would simply be code written into a template file. Ideally you'd split this up a bit more, but just trying to keep it self contained for example purposes. $message = ''; $success = false; if($input->post->pass === 'mypass' && $_SERVER['REMOTE_ADDR'] === '123.123.123.123') { $name = $sanitizer->pageName($inpust->post->username); $pass = $input->post->pass; $email = $sanitizer->email($input->post->email); if($name && $pass && $email) { $u = $users->add($name); if($u->id) { $u->pass = $pass; $u->email = $email; $u->addRole($roles->get('some-role')); $u->save(); $success = true; $message = "Added new user: $u->name"; } else { $message = "username '$name' is already taken"; } } else { $message = "missing required fields"; } } else { $message = "you aren't authenticated"; } $result = array( 'status' => ($success ? "success" : "error"), 'message' => $message ); echo json_encode($result);

Very cool Adrian! A few suggestions: Make your version number 2 rather than 002. PHP might interpret that as Octal or something. Add an ___install() method that does a class_exists('imagick') and throws a WireException if it doesn't. Make the ___install() method add the document_pdf field, or make the module configurable so people can tell it what field to use. Put it on GitHub. Add to the modules directory. Profit! (as Adam would say)

Create a role called "top-level-editor" (or whatever you prefer). Give that role edit permission, but not delete permission. If you want the role to be able to sort children of these top level pages, then you'll want to assign page-sort permission to the role as well. Assign that role to the template used by your top level page(s). Create another role. We'll just call it "editor". Give that role edit, delete, move and sort permission. Assign that role to the templates indicated, but not the templates where you assigned top-level-editor. Don't forget to assign both of these roles "top-level-editor" and "editor" to your user(s) that you want to have this access. I think this was the part WillyC was trying to communicate.

I had to go get some coffee after seeing that photo. Just got this thing yesterday called an Aeropress. The guy that invented the Aerobee (frisbee) apparently locked himself away on a multi-year caffeine binge and came up with this clever device that supposedly makes the best coffee in the world. The coffee beans were just roasted from a place a block away from here, tasty.

You can match in either the filename, description, or tags via any of the DB-find functions too. $pages->find("files=myfile.jpg"); $pages->find("files%=myfile"); $pages->find("files.description*=some text"); $pages->find("files.tags%=mytag"); One thing to note is that description and tags have fulltext indexes, but the actual filename doesn't. As a result, if you need to perform a partial match on filename, you can only use the "%=" operator.

Roy I think something may be amiss with the file you downloaded, or with whatever program is unzipping it. Also, the link you mentioned is to 2.2.9. Be sure you are grabbing 2.3.0, which is linked from the homepage. GitHub keeps changing the ZIP download URL, so I had to update it yet again as recently as yesterday (this time replacing /zipball/ with /archive/).

I'm wasn't seeing that behavior here the other day, as several other pages matched when I tested, but I only copied/pasted enough in here to communicate. I need to go back and test again when in a non-default language. Just to confirm, this is occurring in a non default language?

My opinion is that a good default behavior is to retain the original filename as much as possible. Otherwise you lose relation to the original file on your computer. Usually when a CMS auto-generates filenames, it's because they don't have another means of relating back to the source (Page/id), are using it to define a sort order, or they don't want to go to the effort of making sure the filename is secure (auto-generated names have no user input). Auto-generated names are the quick and dirty way out for a CMS. Never realized they would actually be desirable. If you have a preference for it to auto-generate names like that, it could certainly be done though. One way to accomplish it would be to make a module that hooks before Pagefile::install and rename the file, and send the new filename to the function. That function receives a single argument of just the filename to add. That filename can be local or http, so you'd only want to attempt a rename if local. public function init() { $this->addHook('Pagefile::install', $this, 'hookPagefileInstall'); } public function hookPagefileInstall(HookEvent $event) { $filename = $event->arguments(0); if(strpos($filename, '://')) return; // don't attempt to rename http-based files $page = $event->object->page; // page that will own the file $info = pathinfo($filename); // PHP's pathinfo() function $n = 0; // find the next available filename do { $n++; $newFilename = "$info[dirname]/{$page->name}-$n.$info[extension]"; // my-page-name-1.jpg } while(is_file($filename)); rename($filename, $newFilename); $event->setArgument(0, $newFilename); // update the argument to the install function } The above was written in the browser and not tested, so may need adjustments before functional. What it does is rename the file before it gets added. The do loop may not actually be necessary here, but that is just to account for the possibility that the directory (PHP's upload dir) already has a file with the target name in it. ProcessWire already takes care of adding numbers to files that are placed in it's own assets/files/ dirs.

Makes sense to me. If you guys want to post a replacement function here, I'll plug it in (or pull request, whatever you prefer).

Two issues I can spot here: 1. Your inputs have no "name" attribute. I think you want them to have name="date_start" for one and and name="date_end" for the other. 2. It looks like the PHP code overwrites date_start if both are specified. I'd suggest doing this instead: $selector = ''; if($input->post->date_start) { $startdate = strtotime($input->post->date_start); if($startdate) $selector .= "date_start>=$startdate, "; } if($input->post->date_end) { $enddate = strtotime($input->post->date_end); if($enddate) $selector .= "date_end<=$enddate, "; } // then right before your $pages->find(): $selector = rtrim($selector, ", ");

Who is Dr. Joseph Murphy? Those books I linked to are classics, ones that I have in print and that I think are worth reading in full once a year. They might seem like they are just about money, but that's just how they attracted readership–the concepts are actually much bigger.

I thought that the MODX move was interesting too (as were the EE changes a few months earlier). I don't think it affects anything about ProcessWire, other than that it seems to drive more users here. We won't be following the path of MODX, in case anyone was worried. We get paid by the sites and apps that we develop with ProcessWire, and by the commercial support of modules like FormBuilder and ProCache. I don't have any inside knowledge on the changes at MODX, and may not understand the full scope of them, but here's my outsider opinion about it… I can understand why it is shocking to folks that use MODX, because it kind of destroys the perception of MODX as being a big and stable player. In my mind, they were a big and successful company, and I think that was a lot of other people's perception too. Why would they ever have to rely on a little hosting company with a toilet name and an HTML5 logo? MODX is way above this, or so I thought. The changes instead reveal reality that's probably always been there… MODX is a labor of love rather than profit, as most open source projects are (including us). But MODX has grown big enough in user base that keeping the whole ship afloat means having a team people that dedicate lots of time to it. These people have to be paid in order to take care of their own families, etc. So it looks to me like they are just making the tough decisions necessary to keep the team together and stable. It's not pretty (especially the Siphon part), but digging up the floor to fix the plumbing never is. WordPress has proven that hosting is a safe and viable business model to sustain a big open source project. Supporting other CMSs on the Siphon platform is probably just about risk reduction (put the eggs in a few different baskets… err, siphons… rather than all in one) and it would probably make a lot more than it would cost. None of us should view CMSs as religions. I'm glad that I can run Windows apps on my Mac now, when I need to; that doesn't make me prefer Windows. I'm not sure that having web hosting that can only run MODX would be worthwhile. The value proposition with WordPress hosting (which can only run WordPress) is entirely different. Most people using MODX (and ProcessWire) are professionals that have multiple tools. Most people using WordPress are consumers that know how to write, but don't know anything about web development. Given the different audience, I don't think MODX could duplicate WordPress's hosting success by only hosting one product. But I do think they can be successful by catering to the needs of the audience, which is rarely glued to a single product. If diversifying the eggs among multiple baskets helps to drive development for MODX, then that can only be a good thing. Hopefully that's their intention. If their reality really is as it sounded, then the changes were probably good, even if shocking. I think the fear that people might have is that this is somehow driven by investors trying to monetize the software for themselves. But that just doesn't seem to add up in this case. Instead it presents a lack of sustainability in their existing system that had to be fixed (which is itself shocking). I'm just surprised that: 1) They aren't as big and successful as I thought; 2) They don't have a stronger source of income; 3) Any of this was necessary; and: 4) They told us. I don't think that folks should abandon MODX because of the changes. Their team has put themselves in a vulnerable spot and we should support them. While I don't totally understand their changes, it seems like they are doing this to find sustainability more than anything else. While I support and wish the best for MODX in their changes, I also want to be clear that we will not be following that path. We're already on a beautifully sustainable path here, thanks to all of you.

Sorry to hear about the job loss, but you'll appreciate it later on as you move on to bigger and better things. I think it's good that you've invested time in learning ProcessWire. You know how to use a tool that most people don't, and a tool that lets you easily turn any idea into reality. It will be a money printing machine if you want it to be. Unless you have a lot of bills to pay, don't jump back into something where you are dependent upon another employer for your livelihood. You can make a lot more money working for yourself than someone else, though it does take time to get there. Be useful. But find a way to be useful to millions of people rather than just your boss. One idea is to find a fairly specific subject you are passionate about and think about how you might build an online empire around it over time. But that's just scratching the surface. If necessity dictates going back into another job, then at least save your best energy (early in the morning or late at night) building something for your own future, rather than just your employer. The internet really is the land of opportunity where anything is possible. We have more opportunities than anyone has in history. The more you can make investments in and for yourself and the future, the better.

if($m->viewable()){ A viewable() check shouldn't be necessary unless your selector had an "include=all" or "check_access=0" in it (which it doesn't).

Thanks for reporting back on this. Glad to hear you resolved it.

I like and support code standards, especially the PSR ones. PSR-0 and PSR-1 affect the external use of your code, and provide consistency in how people access your code from the outside. I think these are important standards and am very enthusiastic about them for the most part. PSR-2 is not in the same class. It's a good standard, but is more about internal style than external access. It's one of a few good standards to consider if you are starting something new, especially with a team. But if a project has already adopted a style standard, it would be silly to change from one good style standard to another. The point of standards is unchanging consistency. Changing style standards is counter to the purpose of style standards. I don't think the committee behind PSR-2 would suggest changing from another good style standard to PSR-2. But I do think they would suggest PSR-2 as a solid style standard for new projects, and I would agree. However, PSR-2 is not a clear choice even for new projects. It is somewhat controversial in that it's leaderless committee-design, full of compromises making concessions to differing opinions that don't usually go together. I think the committee-design is apparent in the resulting code style. I'm sure the folks behind it would agree and admit it is a lot of compromise. In this respect, I think it may be weaker than some other style standards, but that's always subjective. However, to focus on how or where it was designed is to ignore the point of the standard. So I very much respect what they were trying to do and have done. I hope that PSR-2 will survive because I think the intentions are good. Though I'm not confident it will be so common 5 years from now. But I think PSR-0 and PSR-1 are here to stay. I hope that folks can understand why it would be a counterproductive (even disrespectful to the purpose of standards) for an established project to change from one internal style standard to another.

Here you are making ProcessWire do the same work twice (not efficient): if(count($page->images->findTag('gallery'))>0) { $gallery = $page->images->findTag('gallery'); Instead, do this (efficient): $gallery = $page->images->findTag('gallery'); if(count($gallery)) { // ...