ryan

That's great! Seems like we just hit the 4k mark, and now we're at 5k. It makes me really happy when I hear people tout one of the main benefits of ProcessWire being the community. That's really encouraging, and speaks to the great group of people here. A couple people had emailed me a year or so ago that I should setup a forum (jbroussa, Adam and one or two others?). All my experiences with forums had been that I set them up for clients and they posted a few messages and then it went dormant. So I thought it would be the same thing here. I couldn't have been more wrong! Amazing that we've got more than 5k posts here in less than a year. I hope we can keep things growing even faster, and always let me know anytime you guys think there's anything we should do to encourage growth here. I'm really not an expert with forums, so always let me know anything I can do on this end to make the experience better.

That setting for the InputfieldPageName module isn't used by $sanitizer. That is just used by the runtime javascript that performs conversions when you are entering characters in the page title (or directly in the page name) field. $sanitizer instead uses PHP's iconv() to perform conversions, and the translations it performs will depend on PHP's locale settings, or you can adjust them with PHP's setlocale() function. Such a thing (iconv) wasn't possible with just javascript (used by InputfieldPageName), which is why it's separate. Though with PW 2.2 and the multi language support, we will likely provide an option to have the $sanitizer->pageName() and InputfieldPageName pull from the same language-specific config data.

Just wanted to keep you all up to date on the multi language support being built for ProcessWire 2.2. The second half of multi language support is now functional – that means multi language support with inputfields and the basic text/textarea fieldtypes. This was necessary since the ProcessWire admin itself is a web site powered by dynamic content. So there needed to be a way to support multiple languages for any field labels and page titles. Since page titles have to be multi language, it's not much of a stretch to make other text fields multi language, so we have that too. For every language installed on your system, ProcessWire will provide 'label' and 'description' inputs for in the fields editor. That way, when someone is editing a page, the fields they are editing will have labels and descriptions consistent with their language. You don't have to use different templates and fields for different languages. You can designate any text field as being 'multi language' by changing it's type to be one of the multi language types. Initially this will include the following: FieldtypeTextLanguage (compatible with any 'Text' field) FieldtypeTextareaLanguage (compatible with any 'Textarea' field) FieldtypePageTitleLanguage (compatible with the 'Page Title' field) We'll also be adding more down the road I'm sure. I think having multi language support for file/image descriptions would be especially useful, so that will probably be next after initial release. When the user has selected another language, a call to any of those fields (like $page->title for example) will return the version in the user's language. If a value is not available, then it returns it in the default language. Multi language fields are implemented at the database level, so when you add a language, it adds another DB field to the database tables used by any multi language fields. This enables the entire API to operate on the user's language. For instance, if the user is using Spanish as their language, a $pages->find("title=coche rápido") will locate that phrase in the Spanish field of the field_title table, rather than the English one. While these multi language fields are pretty fun, it's good to keep in mind that having pages on your site returning different languages at the same URL is probably not a good strategy when it comes to search engines. So I still recommend structuring your site with multiple trees rather than relying on multi language fields. But I do think having the multi language fields will be handy for many things, even if indirectly. But the primary reason we have them is that they are necessary for the admin side of PW since it is itself a web application running in ProcessWire. Here are some screenshots showing what I mentioned above. While everything is now working in the system, I still have a long way to go in working out details and optimizations. So it'll still be a few weeks before I can start sending this out, but we're on schedule and I think we've got a really good system coming together here.

Try this where you output the date: <?php setlocale(LC_TIME, 'es_ES'); // substitute your locale if not es_ES echo strftime('%e de %B de %Y', $page->getUnformatted('date')); // substitute your date field name This should produce the following output for today's date: 8 de noviembre de 2011 We're going to be providing localization support for the date field with ProcessWire 2.2, but the method described here will continue to be backwards compatible. Note you can also put the setlocale() part in your /site/config.php if you prefer. What locale you can use depends somewhat on what are installed on your server. I think that es_ES (or es_ES.UTF-8) is fairly standard, but if you want to get a list of locales you can type this in the unix shell: locale -a

I'm a little conflicted on this because this is something that was in PW1 for awhile, and I later removed it. I thought it would be nicer for the client to have labels for Children (called Subpages in PW1) that could be context specific, like News Items, Press Releases, Articles, Villas, etc. I used it that way for awhile, and surprisingly it made things seem a lot more complex (to the client and to me). PW seems simple because how you edit one thing is how you edit everything, and there really isn't much terminology to wrap your mind around. But once you pull in all these new terms to refer to the same thing (pages) it just becomes a lot harder to think about or even talk about. So I ended up going back to using the same common term regardless of context. At least in my case, the benefits of site-wide consistency ended up outweighing the benefits of custom names. But that was only my experience, and others may have a completely different experience. I'm not opposed to supporting the ability to customize the labels like that, and I actually do think it's a good idea... it just didn't play out well in my case. But I think we'll want to move towards making such behaviors pluggable to give people the flexibility they want in customizing these things.

Nice job Robert, thanks for posting this. Looks to be very well put together. The logo and colors really pop (in a good way) too.

Don't worry about it. I've been guilty of forgetting this too. It's actually an easy thing to forget because in PHP4 objects were not passed by reference... you had to prepend a "&" to them in order to prevent it from creating a new copy on every function call. Thankfully we don't have to do that anymore. But people that have been using OO in PHP for a long time sometimes still use the "&" in front of arguments since it used to be required. When I spend an hour looking at PHP4 code, and then go back into PHP5, I sometimes do the same thing.

The behavior of PHP's array_rand() function (used by getRandom) does seem a little strange when pulling the entire array. I agree with Apeisa that shuffle() is a better way to go for randomizing the entire thing, whereas getRandom is better for pulling 1 or a few elements.

I agree, we'll want to officially endorse GitHub as the place to distribute your modules. The modules documentation is primarily contained in these forums at present. So what really needs to happen is for there to be a real modules documentation in the site (the ball is in my court on this), and that will be the place where we can say people should use Git for distribution. In terms of timing, I'm thinking we'll get this all going together, with the new modules directory on the new site.

It sounds like a good idea for a module. If anyone decides to produce this, just let me know any way that I can help.

Autojoin is a way to have data for some fields bundled into the query that loads the page. It's a way of reducing number of queries for fields that you always want loaded with the page. For instance, you probably always want to load the page's "title" field (a good autojoin candidate). Whereas, something like a large "body" field you probably only need when the full page is rendered. So no need to have that "body" field loaded with every instance of the page (autojoin off). In reality, well indexed and simple MySQL queries are extremely fast, and autojoin may not make that much difference in real use. For example, a couple hundred simple select queries will often run faster than one or two really complex queries. So query counting is futile. But I believe it's still a good idea to use autojoin for fields that you always want loaded with every instance of the page. Most fields do not need to be autojoin. Using autojoin on FieldtypeMulti fields (like pages, files, images, comments, etc.) is a tricky matter because the primary page load query is designed to execute with 1 fetch with no data repetition. That ensures the fastest possible performance. Fields with multiple entries (FieldtypeMulti) are not well suited to being retrieved in 1 fetch. However, ProcessWire can still do it using a MySQL GROUP_CONCAT function to bundle the multiple entires into a string suitable for that 1 fetch. The problem is that MySQL has a byte limit on how much it will GROUP_CONCAT (it's a MySQL setting that we can't count on). As a result, autojoin is okay to use on simple multi-entry fields like Page relations that don't have hundreds of entries–that's because it's just a bunch of integers. But it's not well suited for more complex fields like images that might have long descriptions. As a result, I don't recommend using it with file/image fieldtypes. In PHP5, all object instances are passed by reference. So that particular function is adding on components to the query object to support the autojoin if it can.

Rob, welcome to the forums! Diogo is right that we'll be building a module to handle this natively without having to create your own Fieldtype. But for now you would have to create your own Fieldtype. The image fieldtype may be a bit much to look at because there's so much stuff in there specific to images as opposed to the actual functionality you are looking for. If I'm understanding correctly, you are wanting a field that supports any number of entries with 3 text fields each. Regarding documentation, ProcessWire is still kind of a new project and so I've tried to cover the areas that would be helpful to the most people, and am going back and filling in the rest of the gaps over time. Documentation on how to do things like create your own Fieldtype is something that will be coming. It's basically just a matter of time and resources. We're just 1 year old project and the documentation will continue to grow with the age of the project. So I'm glad to guide people through how to do everything as much as possible, and I'll be glad to assist you with creating the fieldtype you want. My experiences here help me to write documentation as well. Fieldtype vs. Inputfield Creating your own Fieldtype will be a matter of working in PHP and extending ProcessWire's classes. You will need both a Fieldtype and an Inputfield. The two work together. It's good to understand what both are. The Fieldtype defines the data's type and handles loading, saving and sanitizing the data that is added to a page. Whereas an Inputfield does nothing other than provide the HTML form inputs to collect the data, and then retrieve the posted data when it's been submitted. As a result, an Inputfield only comes into play in the admin when you are entering data. Whereas the Fieldtype is always active any time the data is loaded. To put it another way, if you only ever populated data in ProcessWire with the API, then you wouldn't even need an Inputfield. In many cases there is a specific Inputfield for each Fieldtype. But there are also many Fieldtypes that can work with an existing Inputfield too. For instance, the FieldtypeTextarea can utilize InputfieldTextarea or InputfieldTinyMCE, according to your need. In your case, I think you'll want to create both a Fieldtype and an Inputfield specific to it. Fieldtype vs. FieldtypeMulti In ProcessWire Fieldtypes fall into a class of either Fieldtype or FieldtypeMulti. The only difference between the two is that Fieldtype supports one entry per field per page and FieldtypeMulti supports any number of entries per field per page. An example of a regular Fieldtype is FieldtypeTextarea, which would simply be one textarea input. Examples of FieldtypeMulti are FieldtypeFile, FieldtypeImage, FieldtypePage, and FieldtypeComments. Regardless of whether a Fieldtype or a FieldtypeMulti, ProcessWire reserves one database table per field. This means you can build complex Fieldtypes containing multiple fields of data per entry. While not many fieldtypes demonstrate this, Fieldtypes are specifically designed to represent complex data types in the database and in the API. FieldtypeComments is currently the most complex public example as it's schema contains many fields per entry. Creating your own FieldtypeMulti If you are still interested, here are some links to get started. Let me know if this stuff makes some sense to you (you don't need to understand it all), and then we'll use this thread to start building a simple FieldtypeMulti. Once we've got something working, hopefully we can take parts of this and turn it into a Fieldtype tutorial. Discussion and example module of how to expand the schema of the Image fieldtype http://processwire.com/talk/index.php/topic,466.0.html The Fieldtype base class (read the comments for each function): https://github.com/ryancramerdesign/P21/blob/master/wire/core/Fieldtype.php The FieldtypeMulti base class (read comments, but not as important as Fieldtype): https://github.com/ryancramerdesign/P21/blob/master/wire/core/FieldtypeMulti.php (ignore the commented out code, I've just kept some things commented out for future reference) The Inputfield base class (don't spend too much time, just take a brief look): https://github.com/ryancramerdesign/P21/blob/master/wire/core/Inputfield.php Simple Inputfield example implementation (integer field): https://github.com/ryancramerdesign/P21/blob/master/wire/modules/Inputfield/InputfieldInteger.module

Sevarf2, I can't seem to duplicate here. I started from a new install and pasted this into a template: <?php $p = new Page(); $p->template = $templates->get('basic-page'); $p->parent = $pages->get($user->id); $p->title = 'Submissions'; $p->save(); Then ended up with this page: /processwire/access/users/admin/submissions/ Can you think of any other factors or other modules that might be running? I'm also curious about the page name "0". I just committed an update that may fix this in your case–can you grab the latest commit and let me know if that fixes it? Thanks, Ryan

I agree with Adam about using inline styles. There is a place where inline styles are appropriate, and this seems like a good example of one. Also, jQuery/Javascript is another thing to consider.

Thanks! We need all the backlinks we can get. Always much appreciated. Some of my clients don't want anything to say who made the site or what it's running, so I totally understand there are many cases where it's simply not possible too.

Thanks diogo!

Thanks for finding a solution here Soma. I will test and add to the core source.

It seems like a great way to do it. Admittedly, i'm not quite at the level with Git where I understood everything that was going on in that tutorial (and you just motivated me to put in an order to Amazon for a book on Git). But this seems not far off from what I'm already doing to keep my PW installations up-to-date, as well as 3rd party modules. I've not used Git submodules before, so that's something new to me. Currently I'm keeping my 3rd party modules as individual repositories. Since I'm running multiple PW sites on one server, I'm using symlinks to link in any modules I want with a site (1 repo per module, shared among multiple sites). It seems really simple, so not clear what advantage submodules would have over this. Though there may be some significant differences in the file layout structure of Symphony and PW that necessitiate the approach they are using. But like I said, you motivated me to buy a book so I can put some real time towards getting more in depth with Git. I have a feeling I'm missing something obvious. Ultimately I'd like for people to be able to add and update modules from the admin without having to go through version control or even their file system. It'd be great if they could just plug in a URL to the module and then have PW take care of installation and notifying them when it needs an update. That's a ways off, but I'm just thinking that it's got to be as easy as possible. To me, the people using Git to manage their site are more the hard core users and open source developers that really know their way around, and that's just one segment of our audience. I think that almost all the PW modules are available on Git at present. Usually we'll post to the forum for test versions, and then post to Git once things are pretty well set and ready for distribution. This is what I'd recommend for all modules. Perhaps this should be a pre-requisite to be listed in the module directory on the new site.

It sounds like a bug, but it's actually just something that's not automated in the system (and I'd forgotten that it wasn't). A page checks for changes when something is set or added to the page itself. But a property down two levels of objects is not something a Page knows internally to check (and it wouldn't make sense for it to). So that object has to instead notify the page, or at least its parent object, that something has changed. So it's something that I think I can automate, but it's one of those things I'd want to do a lot of testing with to make sure I'm not screwing up anything else. So in the short term, I would suggest continuing to use the $page->trackChange method to let the page know about the change. In the future when this is built in, it won't be necessary, but also won't hurt anything to keep it there. The reason this isn't an issue with PageEdit (for example) is that PageEdit doubles up on change tracking by checking the Inputfields themselves for changes. It basically does this: if($inputfield->isChanged()) $page->trackChange($inputfield->name); Btw, the purpose of change tracking is so that PW can avoid the overhead of saving all fields on the page, and instead just focus resources on the fields that have actually changed.

I'm worried about implying that one is editing the properties of the field within the context of the template. Whereas a field is something that exists separately from a template and can be used by any templates. As we move forward, I would like to have a way for fields to have a template context, so one could modify their labels or behaviors according to the template they were placed in. Once we've got that, then I think the edit links will be right at home. This one will be easy! We've got the ProcessPageSearch built to support selector queries, so it could be done with a simple link to: /processwire/page/search/for?template=basic-page (or substitute name of template) I agree about dropdowns, and this is something I will definitely be adding to the default admin theme. I like what Soma has done here too. Though I want the template names and field names to be directly selectable from the second level of the dropdowns as well. The only reason dropdowns aren't already in place in the default admin theme is that I'm determined to get this multi language support in place before anything else.

Martin, do you know if there are any documentation/demonstrations/videos of Symphony's method here online? Just looking for a good starting place to read more about what they are doing in this respect.

Pete, thanks for your great work on this module!

drilonb, in your case it would be more efficient to use PW's built in pagination. The only reason Robert Zelnick had to use the method he did is because he wasn't working with pages. Pages are built for pagination, so they have things to make it more efficient and easier. When you call 'children' without any selector, it has to load all the children. If there are hundreds or thousands, that could be lot of unnecessary overhead. This is a preferable way to do it with pages: // only has to load $limit children $pages->get('/events/')->children("start=$start, limit=$limit"); Whereas this is not a good way to do it with pages: // has to load ALL children $pages->get('/events/')->children->slice($start, $limit); Also, using the "start=" isn't necessary when using built-in pagination because PW does that automatically behind-the-scenes from the page number. Though you can certainly use it, but it's just not technically necessary. Lastly, when using built-in pagination for your 'next page' link, you want to use $children->getTotal() rather than count($children). The reason is that count($children) would only have $limit items, whereas $children->getTotal() would have the total number of items if it had loaded them all. So you'd want to replace this: if($start + $limit < count($pages->get("/events/")->children)) { …with this: if($start + $limit < $children->getTotal()) { And there's no need to keep your own $start or $limit variables since PW is already keeping them for you. So you could just do this instead to determine whether to show a 'next page' link: if($children->getStart() + $children->getLimit() < $children->getTotal()) {

That's correct, the template has to manage access to control what it's behavior will be here. Otherwise, it'll inherit the behavior from what parent is defining access.

There's actually nothing wrong with using the PHP vars like $_GET and $_POST (or $_REQUEST if necessary). But ProcessWire saves you the step of having to check for magic quotes, so it's usually easier to use the ones that PW supplies. But if you are checking for non-string type stuff (that would never have quotes) then it doesn't matter much what you use.