ryan

Matthew is already working on a site directory for us, so he may have some thoughts too (?). I think if someone wants to put time towards making ProcessWire look good, that's always a good thing. One thing is for sure, we definitely need more showcasing of sites built with ProcessWire. If there is more than one showcase, I don't see that as a problem at all. Just more opportunity to reach a broader audience.

I would think that whatever you pass in would overwrite any defaults already present? That way, if you want to override something, you can. If you don't want to, then you leave it out. I guess the question is whether there is any value to overwriting the variables that are already populated in the template. The only one that seems like it could have value would be $page. Until I think about it a little more and… what would be the point of calling $page->render(...) if you were going to overwrite the $page in it. It would be more logical to just find the $page you want and call its render() method instead. Maybe throwing an Exception does make sense. Though need to think about it a little more.

I'm not clear about the question. What is the source of the URL segments you'd want to use?

This makes the events consistent with how they are in the Pages class, which I think is a good thing. They are more reliable to standardize upon because, for example, saved() is called only after an item has been saved without error, and saveReady() is called only after its been confirmed the item will definitely be saved (no conditions to prevent). Without these, your hooked functions have to consider these things themselves (at least, if you want them to be thorough). Granted, there are more potential conditions within Pages than here, but these are hooks that probably belong here either way. I was just looking for a good reason to add them. While I think you may be able to do what you need without them, feel free to use them if helpful, because they belong here.

This sounds awesome mindplay.dk! That's a valid concern, since modules or other API usages that are adding/manipulating templates/fields would not be triggered from the Process ones. Though if you only wanted to capture changes made interactively, that would be the place to do it. Attached are replacements for /wire/core/SaveableItems.php and /wire/core/Fields.php. They contain additional hooks, which I think may be more what you are looking for. Let me know if these work out, and I'll commit them to the core. I'm a little short on time this afternoon, so haven't had a chance to try them myself, though the additions are very minor and simple so can't think of any reason why they wouldn't work. mindplay.zip I added a few hooks to SaveableItems.php which is used by both Fields and Templates. You can hook these either by wire('fields')->addHook('methodToHook', $this, 'yourMethod') or $this->addHook('Fields::methodToHook', $this, 'yourMethod'). To operate on templates, you would replace 'fields' with 'templates'. Here are the hooks, and they work exactly like their Pages class counterparts: public function ___saveReady(Saveable $item); public function ___deleteReady(Saveable $item); public function ___saved(Saveable $item); public function ___added(Saveable $item); public function ___deleted(Saveable $item); These two were also added to the Fields class (in the attached zip): public function ___changedType(Saveable $item, Fieldtype $fromType, Fieldtype $toType); public function ___changeTypeReady(Saveable $item, Fieldtype $fromType, Fieldtype $toType); For all of those above, it doesn't matter if you hook before or after. For the existing hooks that were already there, it does matter whether you hook before or after. Though not sure if you necessarily need any of these: protected function ___changeFieldtype(Field $field); // Fields class only public function ___saveFieldgroupContext(Field $field, Fieldgroup $fieldgroup); // Fields class only public function ___clone(Saveable $item); public function ___delete(Saveable $item); public function ___save(Saveable $item); protected function ___load(WireArray $items, $selectors = null); Let me know if there is anything else I can add/adjust to facilitiate what you are working on.

I agree with Soma, it sounds very doable to me. Let us know if you run into any specific problems as you go.

It's in kind of small text on the MySQL config screen:

I'm not clear about what the pages are. Can you post a screenshot from your admin so we can see?

It's in the dev branch now

Thanks Soma, that one is fixed now.

Maniqui, Thanks for your suggestions. Regarding the missing commits, it appears that GitHub is not giving the correct information about this, or maybe I'm misunderstanding. All of those updates are on both branches. I went through each of the items to confirm. As an example, look at the second one 9b3039d which says "Fix issue with RepeaterPageArray lacking a makeNew() method." But I can go and see that this was updated on both branches: master and dev. The same goes for all the other updates. Let me know if I'm missing something. I will go ahead and tag it 2.3.0 here. But I'm not sure this would have resolved the 2.2.9 and 2.2.9-final, because I didn't realize 2.2.9 had commits after the original tag until I was merging in 2.3. I honestly don't know what happened there, but probably some workflow/user error on my part. What would have solved it here is if I had another component to the version number so that the dev branch could have an incrementing version that didn't potentially conflict with a master version. That way someone could say, I'm running 2.3.0.3 or "2.3.0 dev 3" and I know by that extra "3" at the end that it's a dev branch revision. Then once ready to merge to master, it would become 2.3.1 on master and 2.3.1.0 in dev. This seems like a workable route to me, but let me know if you can think of a better route?

I just posted an update to the LanguageSupportPageNames module that appears in the 2.3 dev branch. The screenshot explains it best: Basically, you can uncheck the "active" box for any language, and that page becomes unpublished, for that language only. It behaves the same way as an unpublished page, in that it doesn't show up in searches, and produces a 404 if you try to view it (unless it's editable, in which case you can still see it). You don't see a checkbox next to the default language, because that one is controlled the same way as before (via the page's unpublished status).

I don't really see HTML tags being indexed as a problem. I've taken advantage of that on a few occasions and was glad it was there. Honestly, I've never had the need for more than the built-in text searching capabilities. Though my needs aren't everyone's either, so not saying there wouldn't be a need. There have been times when one operator or another better suited a particular client, whether %= or ~= or *=, but I've never had the need to use an external solution. There have been one or two instances where I had a large quantity of fields that needed to be included in the search, and it became a potential bottleneck. This is part of the reason why the FieldtypeCache exists. You can bundle all of your text fields into one, and then search the cache rather than the individual fields. So you would search for "field%=some text" rather than "field1|field2|field3|field4%=some text". It works quite well for this. It's been awhile since I've had the need to use it, but it's one of the original core Fieldtypes and worth looking at if you run into a similar issue of too many fields to search, or needing those fields to be in the same block for ranking purposes. (Search ranking works a little bit differently when the combination of fields is ranked vs. individually ranked as separate fields). As for external search engines, I think it would be hard to beat something like Google CSE (if that's what they still call it). I've also used Sphider as a self hosted PHP-based solution, and was quite happy with it at the time… though this was before ProcessWire existed. But it still seems to be an active, and highest rated (to Google) PHP search engine. It does include the ability to index PDF, DOC and other files, though requires external converters. If I recall, it works quite well for that though.

Great site Nico!

If you don't want to re-trace steps of page, field or template creation, you may want to share a database server with your team. It doesn't matter what system you are working in, if everyone is running their own copy of the database, that's something that needs to be resolved when pushing them back together. Another option is to use the API to create your pages/fields/templates and script them. But the reality is, most of one's work in ProcessWire typically isn't in the creation of these things–instead, it's working in code. So your best bet is to write code that doesn't rely upon specific database IDs, and instead abstract to retrieving things by name, path, template, etc.

I haven't seen that particular error in a long time. What version of ProcessWire? The LanguageSupportPageNames module is only advised for development and or testing purposes at present. It will be ready to use in production over the next month.

Welcome Andy! You had me at the avatar, but then the George Bush art show, and the politics and market analysis… truly interesting first post. And great to work on projects that are outside of the matrix for sure, this is one thing I love about open source. Glad to have you here.

The DB configuration screen of the installer should tell you what are the minimum permissions PW needs to run. To the best of my knowledge, ProcessWire doesn't currently use trigger, show view, execute, create view or create routine, and possibly a couple of others. But that's not to say that it won't in the future or that 3rd party modules don't/won't ever use any of these. If there are any specific privileges that make you uncomfortable, you can always experiment by disabling them. But don't disable that the installer says are required.

Fieldtype or Inputfield? The password requirements only apply to the Inputfield (interactively). There isn't really much reason to use the Inputfield on the front-end of your site unless you are using it with FormBuilder. From the API side, you can configure the minimum length setting for the Inputfield: $inputfield->minlength = 30; // default is 6

Checkboxes can't be checked by default. This is to ensure you use scalable conventions in creating and maintaining your site. For instance, if you added a checkbox to an existing site that already had thousands of pages, and made the default "checked", then that would only apply to newly created pages from there … all of your thousands of existing pages would still be unchecked. Confusion, problems, and potentially a whole lot of work ensues. Whereas if you use checkboxes to toggle a non-default behavior, that is much more scalable and predictable.

Thanks Diogo! Seems to work very well. I've added to the source and will test locally for a day or two, then push it to the dev branch.

Just to follow up, you are right that namespaces will solve this. And they are coming in 2.4. Otherwise, the only options are to rename one of the classes (and anything referencing that name), or let your applications talk to each other via some other route, like web services.

Valery I think your analysis is correct. An opcode cache and ProCache are very different animals, as you've identified. Ideally you have both. There really isn't any crossover between the two because an opcode cache only comes into play when PHP is active. ProCache bypasses PHP, making the request completely static (and thus a lot faster than one delivered via a PHP opcode cache). The apachebench results I posted in the ProCache thread were actually with APC enabled. While ProCache can technically make a bigger impact on front-end performance, ProcessWire is a PHP application and having an opcode cache is a good idea either way. I would guess that most of us are already running some kind of opcode cache whether we know it or not (usually APC, eAccelerator, etc.)

Thanks guys, glad you like the updates! This is of course building off of the work that Adam, Soma, Apeisa, Teppo (others?) already did in developing the new site design. I'm just filling in columns.

Repeater fields don't have this as a configuration option at present. So enforce your limit from the API side. Here are two ways you could do it (the first would technically be a little more efficient): foreach($page->list->slice(0,3) as $item) { ... } foreach($page->list->find("limit=3") as $item) { ... }