ryan

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.

It does work for me. Are you sure you don't have one of the other fields populated, like parent or template? Let me know if you can think of anything else I might try to duplicate here. Also, regarding Antti's question -- are you using an asmSelect with a 1-page reference? asmSelect is only meant for multi-page references.

Nevermind about this, I was wrong as that limitation never made it into the code at GitHub (was already fixed before I pushed it to GitHub). I tried this as my selector with a multi-page field using asmSelect: parent=/building-types/, template=airports|aquariums It worked for me, showing the selectable pages I wanted it to. Is there anything else I need to do to duplicate?

I couldn't duplicate this until I tried with changing it to a single-page field rather than multi-page field. That did it, I could duplicate it. I looked closer and see we have an optimization that enforces the parent at load time, but only for single-page mode. Usually this optimization would be good, as it gives a slight performance edge. But obviously it's not good with PageListSelect, so I removed it. Thanks for finding this. I've committed the update to the 2.2 source. Is this paired with one of the PageListSelect inputfields? You mentioned asmSelect, but since PageListSelectMultiple also uses an asmSelect style sort list, I'm not sure. You probably saw the note with 'selector' and 'template' where it says "This is not compatible with PageListSelect inputfields". However, it should be compatible with a regular asmSelect Inputfield. But you might need to use parent=123 (page ID) rather than parent=/produckte/, though not for long (already a fix for that but still tweaking it).

Oliver, I'm not certain without seeing some code. If you'd like, PM or email (ryan at this domain) and I'll be glad to take a look. Is the page you've added your Process module to using the default 'admin' template, or something else? If not the 'admin' template, then note that you'll probably want to have URL segments turned 'off' in your template settings I think you already understand this part, but I'll describe how Process modules work with regard to URLs. If you have a Process module you've assigned to page /languages/ and you access that page, then the execute() method of that process will be called, and whatever it returns will be displayed. But if you access the URL /languages/add then it's going to call executeAdd() instead, and likewise if you access /languages/edit then it's going to call executeEdit() instead. There are no predefined segments, so it doesn't have to be "add" or "edit", but it can be whatever you want it to be, so long as maps to an execute[segment] function in your Process module.