ryan

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.

Let me know when you think it's stable/ready, as I'd really like to have this built-in to the core. It doesn't seem like there's any real overhead to this, just a very handy tweak to have when you want it. I can see using this quite often. One question: when you are copying/pasting, say from Photoshop, where does the JPEG compression actually take place? Does Chrome compress it as it pastes, or how does that work? Great screencast BTW!

Absolutely! That sounds great. Thanks for getting it working in nginx.

Subdirectory vs. root doesn't matter. Most likely ProcessWire can't get sessions started. Try removing your /site/assets/sessions/ dir completely, and then re-creating it. Give it whatever permissions are necessary for ProcessWire to write to it. If you do 777, and this is not a dedicated server, then check with your systems administrator to see if you can lock that down a little better.

Soma is correct. You need to replace "limit = 10" with "limit=10".