ryan

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) { ... }

This would be a fine way to go. Since you can't have a checkbox "checked" by default, you would want to use and name/label your field accordingly and use your checkbox to toggle the non-default behavior when checked. ProcessWire doesn't know the difference between navigation and searches. Every API call to ProcessWire is a search, whether you are using it for navigation or not (ProcessWire doesn't know what you are using it for). If "hidden" is checked, then it excludes it from the search, unless you add "include=hidden" or "include=all" to the selector. So if you want a page to be excluded from both navigation and searches, then you would want to make it hidden and avoid having a "include=..." in your selector. There are also other built-in ways to exclude a page from appearing in results from API calls, including the "unpublished" status, and access control.

This sounds like a good solution to me. I can see this being useful. Though I'd probably want to make any relative paths relative to the /site/templates/ dir, just to prevent any ambiguity about the starting point.

Check your javascript error console. There is a 404. Your AJAX is trying to load the URL with a period "." appended to it. I'm guessing you've got an extra period somewhere in your javascript. I'd also suggest adding an extra slash to the end (to avoid an unnecessary 301), unless you've specifically disabled slashes in the template's URLs tab. GET http://webking.gr/web_design/website-web-design-web-development. 404 (Page Not Found) Note the period at the end of the URL above.

The matches() function has actually been moved to be part of the Password value itself, so this is one thing I will add to the 2.3 API docs.

Most of ProcessWire's admin can function without Javascript, but sections of the admin that rely upon asmSelect's sortable functionality require javascript. I think the Template edit screen is the primary one that would be problematic. The PageList should technically be able to function without Javascript (though haven't tried it in awhile), but you lose the ability to drag-sort of course. I'd always intended the admin to be workable without JS, but the demand for it has never come up, so it's not had much focus since version 2.0 was released.

Yet another option would be FieldtypeConcat, where you can combine the output of multiple fields into one, and then use that field as your page list label.

That's true that the complexity requirements aren't configurable at present. Though I could feasibly make it configurable, but this is the first time the request has come up. Currently, the requirements are that the password must have at least 6 characters, one of which must be an ASCII letter of a-z or A-Z, and one of which must be a digit (0-9). These requirements are only enforced interactively, and in the PW admin. So if you populate a password to a user from the API side, like $user->pass = 'something'; there are no requirements. Meaning, you can choose to enforce your own requirements before populating $user->pass with a value.

The CKEditor module is beta, and if you guys any config options that you think we should add to it or anything like that, just let us know.

What's interesting to me is how similar forums like this are to the way BBSs were, at least with regard to the community aspects. Though with many good BBSs, you always had to redial dozens of times before you could make a connection, so you really had to be committed. In my case, I was sometimes spending a couple hundred dollars a month connecting to BBSs in Europe (like Future Crew's Starport BBS in Finland) to download the latest demoscene releases to distribute them in the US. It was a costly hobby.

I do it all the time here. You are right that it's a good idea to make it use a different session name for each. Being logged into one of the PW instances doesn't have you logged into the other, either way. @harmster: you can always disable the CSRF protection too by editing your /site/config.php and adding: $config->protectCSRF = false; That's not an idea solution, as having CSRF protection is a good idea. But it will solve it until you can find another resolution.