ryan

Great site Marty--Fantastic work!

ProcessWire is very different from something like WordPress, where one would browse and install pre-made site themes. There aren't pre-made sites to go (other than the default profile, at present). This is because the audience is one that wouldn't typically use them anyway. Our emphasis veers more towards designer/developer tool, where the needs of the individual site tell the CMS where to go and what to do, rather than the CMS telling the site what to do. This is the opposite of something like WordPress. Though the line can be difficult to envision because ProcessWire can do everything WordPress can do, but WordPress can't do the things ProcessWire can. Think of ProcessWire as a tool more like jQuery, where it's there to help you build what you want, rather than build it for you. Though I don't want to suggest that ProcessWire is limited to that. But that is what separates ProcessWire from other systems. In the future, I'm sure we'll get into providing ready-to-go sites and themes too (it's easily possible now), but we're most geared towards supporting the professional designer/developer community now. I still think WordPress is the best tool if you want to pick out a theme, and put up a site without developing it. But we will broaden in to this area as we grow too.

This is my mistake, I sent in you in the wrong direction with regard to $user before. (Sorry about that) $user is actually still the one that was originally supplied to the template (guest). So you need to use the $user returned by the login function. Change your login line to be this: $user = $session->login($input->post->user, $input->post->pass); if($user) { // login success if($user->isSuperuser()) { // now this should work } } The only reason this is necessary is because $user was supplied to the template before the login occurred, so that user is still 'guest' unless you change it (like above).

Looks like a great solution, thanks for posting Diogo. A couple of suggestions I'd have would be: 1. For all your $pages->get("title=$email"), I'd suggest making them as specific as possible since they can be initiated by a user. Specifically, I'd make it "title=$email, template=person, parent=/subscribers/". While not technically necessary, it just puts in another layer of security at very little expense. Who knows, maybe you'll use email addresses for titles somewhere else? 2. You may want to consider changing your $page->delete() to a $pages->trash($page), just to give you the opportunity to review who unsubscribed before emptying.

Definitely sounds like a great idea and I agree about the value of it. If you decide to pursue such a projectm let me know how I can be of help.

Count me in to help anywhere needed too. I don't consider myself an ecommerce expert, so not really sure on best approach with a lot of things, and don't think I'd be the right one to lead such an effort. When you get into supporting multiple gateways, shipping methods, currencies and such it becomes quite a complex thing. As a result, I've always delegated ecommerce to other software. Currently I run Drupal UberCart and Shopify. I've also run OSCommerce in years past (what a mess that is). The thought of having a PW-based solution is attractive.

That's correct that the method currently in the core does require it's own site directory and database, though shares the same PW installation and web account/web root. It's an entirely different method than what we're talking about here. But I've just been trying to mention it as a side note in any related discussion (not always sure who's looking for what). The code outlined in this topic is more of an untested theory. Though I don't see any reason why it shouldn't work. I would eventually like to have a core method for running sites on the same DB too.

Thanks for reporting back. Glad to hear it's working how it should.

PW 2.2 uses a newer version of TinyMCE than PW 2.1, so there have definitely been changes in this area. But I've not seen this behavior with line breaks. Are there any specific steps I'd need to take to duplicate? I've tried making several edits here but am still getting the expected <p> tags. The only way I can get a <br /> is if I use shift-enter.

Are you saying that you set it directly in code? What I actually meant was that you'd wan to edit the homepage template, click on the 'URLs' tab and check the box that says to enable URL segments. Though if you needed to do it in code (like for a module installation or something) then you could do this: $homepage = $pages->get('/'); $template = $homepage->template; $template->urlSegments = 1; $template->save(); But unless you are building a module install() function or something like that, I recommend just going and editing the template settings directly. Also note that we now have core support for multi-site support using separate /site/ directories: http://processwire.com/api/modules/multi-site-support/

Thanks for the kind words and recommendation Joshua! We appreciate it. I likewise have very positive thoughts regarding HTML KickStart. I hadn't known about it until recently and am really impressed what what I see. Something that comes to mind is a possible future ProcessWire site profile that's built around HTML KickStart (if you aren't opposed to it), some really cool possibilities. I look forward to experimenting more. Thanks for making this great framework.

Currently you can't have a textformatter configurable with a field's settings, though a textformatter can be made configurable in the module settings (where you could workaround that). But perhaps I should find a way to enable textformatter config options with the field.

I think this looks pretty nice. Could be a good replacement for the debug mode we've already got. I have no idea yet if it'll work with PW, but I'm going to give it a try. Thanks for letting me know about it!

Soma, sounds like you've got it right. If you want the default language to be German, then just throw in the German files into the default language. There's nothing English about the default language except for the name "default" (which you uncovered the reasons for). But if you want to connect the language to a code like "de", then I suggest creating a new field called language_code and adding it to the language template. When you want to select a language, just use "language_code=de" in your selector. When you create your English language as an alternate, you won't need to upload any JSON files for the admin side of PW unless you want to change the English that is already there. I don't think there's any reason to gravitate towards keeping 'default' as English, unless it really is your site's default language. But if you want to do that for some reason, then you would just edit the 'guest' user account and change guest's language to to be 'de' or whatever you want your site's default language to be.

I saw that too--good to see. It looks like he's also using ProcessWire to power that 99lime.com site.

It is possible, but you'd have to modify the Comments fieldtype and inputfield to do it. As a result, it may be something you'd want to wait for the updates, unless you need it right away.

You've found a bug. Try putting a space before your '_n' ( and that'll fix it. I should have a proper fix committed here in a couple minutes. Thanks for finding this. Ryan

Adam you want to use the Selectors class. Try running this example, which should answer a lot of questions: $str = "a=1|2|3, b<=1, c*=xyz|some, d>10, e|f=something, g!=nothing"; $selectors = new Selectors($str); $tests = array('0', '1', '3', '9', '15', 'Adam', 'abcdefghijklmnoprstuvwxyz', 'something', 'nothing'); echo "<ul>"; foreach($selectors as $s) { echo "<li>" . $s; echo " (" . $s->field . $s->operator . $s->value . ")"; echo "<ul>"; foreach($tests as $test) { $matches = $s->matches($test) ? "<strong>Matches</strong>" : "Does not match"; echo "<li>$matches: $test</li>"; } echo "</ul></li>"; } echo "</ul>";

Clinton, I've updated the module to support this. You'll find it in the latest commit in the PW 2.2 source. To enable, specify '0' as the max length for the description field in the module settings. Can you confirm that this solves the issue and enables use of the full article? Thanks, Ryan

main.php just refers to a main markup template. It would be the same thing as a head.inc and foot.inc combined. But many use a main.php rather than separate header/footer includes.

ProcessWire 2.2 is already released, so the term "hard launch" would refer to the date when we send out press releases to various sites to announce it. Before that happens, I want to get an official language pack section setup on the site and wrap up a bit more documentation. I would say we'll do a hard launch in two weeks, roughly. But don't wait to upgrade to PW 2.2, as it is now considered the stable version.

That's great to hear Google can execute JS and index stuff from it. That's quite a technical feat, I'm impressed. I did some testing a couple days ago with Disqus and found Google wasn't indexing them. But it may just depend on the site, widget version, etc. But the fact that they CAN definitely changes my opinion about javascript-based comments. However, I still have to believe there are major advantages to staying in control of the markup and accessibility of your comments… but just not as many as before. Things are always changing for the better.

Sorry, I misunderstood. If those files are only going in the places that need it, then the concern I had is not applicable. Not necessarily. When a file is on a protected page, ProcessWire could spit out a link to the passthrough script as the $file->url(), like domain.com/files/123/somefile.pdf, rather than to its protected location in /site/assets/files/.123/. The $file->filename() property would still refer to the actual disk path since htaccess limits aren't applicable there.

Thanks Dave, you are right, that's a typo on my part -- it should be explode().

No matter where you use a selector like "parent=/path/" in the API, it's always going to refer just to direct children of that parent. The selector used in this field setting exhibits the same behavior as the rest of the API. I think what you might be looking for instead is the "has_parent" selector option, which is a way to refer to a page having a parent anywhere in it's ancestor tree. You won't see "has_parent" used in the API very much (or ever?) because you'd typically do this instead: $pages->get('/products/')->find('template=product'); But behind the scenes, that actually translates to this: $pages->find('has_parent=123, template=product'); 123 is the ID of /products/. The "has_parent" has to be used with an ID rather than a path, though I'll probably change that, now that there's an external use for it.