ryan

This is correct. I don't think there is any crossover between what your module is doing and the new Languages modules being built for PW 2.2. I am very excited about what you've put together here and can't wait to try it out.

Thanks for the screenshots. This is strange–I've not seen this behavior before. I would think you'd get an error, but clearly none is appearing. Can you confirm that it started after you migrated the site to your live server? Are you getting any JS errors? (you may have to enable the JS console in your browser). What browser and version? Can you think of any other unique factors that might enable me to reproduce it?

Here was Ryan's example code for calendar, until I (apeisa) modified it instead of quoting... I got the original back from my editor, I post it here as reference. Ryan - sorry I lost your message here. You wrote something about that it is fun to code calendars -apeisa <?php $year = (int) $input->urlSegment1; $month = (int) $input->urlSegment2; if(!$month) $month = date('n'); // if no month, use this month if(!$year) $year = date('Y'); // if no year, use this year $startTime = strtotime("$year-$month-01 00:00:00"); $endTime = strtotime("+1 month", $startTime); // find all events that fall in the given month and year $events = $page->children("date>=$startTime, date<$endTime"); // get all the info you need to draw a grid calendar $weekDayNames = array('Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun'); $firstDayName = date('D', $startTime); // i.e. Tue $daysInMonth = date('t', $startTime); // 28 through 31 // make the calendar headline $out = "<h1>" . date('F Y') . "</h1>"; // i.e. October 2011 // create the calendar header with weekday names $out .= "<table><thead><tr>"; foreach($weekDayNames as $name) $out .= "<th>$name</th>"; $out .= "</tr></thead><tbody><tr>"; // fill in blank days from last month till we get to first day in this month foreach($weekDayNames as $name) { if($name == $firstDayName) break; $out .= "<td> </td>"; } // draw the calendar for($day = 1; $day <= $daysInMonth; $day++) { // get the time info that we need for this day $startTime = strtotime("$year-$month-$day 00:00:00"); $endTime = strtotime("+1 day", $startTime); $dayName = date('D', $startTime); // if we're at the beginning of a week, start a new row if($day > 1 && $dayName == 'Sun') $out .= "<tr>"; // create the list of events for this day (if any) $list = ''; foreach($events->find("date>=$startTime, date<$endTime") as $event) { $list .= "<li><a href='{$event->url}'>{$event->title}</a></li>"; } // if any events were found for this day, wrap it in <ul> tag if($list) $list = "<ul>$list</ul>"; // make the day column with day number as header and event list as body $out .= "<td><h2>$day</h2>$list</td>"; // if last day in week, then close out the row if($dayName == 'Sun') $out .= "</tr>"; } // finish out the week with blank days for next month $key = array_search($dayName, $weekDayNames); while(isset($weekDayNames[++$key])) { $out .= "<td> </td>"; } // close the last row and table $out .= "</tr></tbody></table>"; // output the calendar echo $out;

Can you clarify what you mean by disappears? Are you saying it gets deleted from the file system, or that something visually on the screen disappears? If on screen, is the file there when you save or come back to the page?

I don't think your htaccess file will matter in this case, because the error you are getting is one that involves a file access not controlled by apache. Since you mentioned it started when you moved a local project to the server, I'm guessing that something in your /site/assets/ isn't writable or some of the directories didn't make it over. Try to re-copy your /site/assets/ to your live server, and then double check that everything is writable. If it's a unix server where you have shell access, you can do it pretty easily just by executing this command: chmod -R og+rw /site/assets

YQL definitely sounds interesting to me. I look forward to learning more. I've been working with a lot of XML data feeds lately. Currently building a system that mirrors articles from a content provider a couple times a day and I'm pretty impressed by their web services. Lots of feeds to pull from between articles, images, comments, categories and more. Regardless of format, PHP's SimpleXML + ProcessWire makes it really straightforward. There's nothing more satisfying than pulling data from web services and watching a site run itself. So something like YQL sounds very intriguing.

These are great links, thanks Martin!

Hi Nico–can you provide more details on how to duplicate this? It's not something the occurs during my use, so I was just curious if there is any factor that you think is triggering it?

A side benefit, but I also really like being able to make all my select option pages use a template that displays all the pages that have that option selected. They are really useful, and search engines love these pages too (these cross references are priceless). For instance, your 'option' template might have this: <?php $results = $pages->find("field=$page"); // replace 'field' with field name echo $results->render();

Well actually you can do this. When outputFormatting is off, your $page->title field (for example) is actually an object that contains all the language versions. If you treat it as a string, it'll return the value in the user's current language. But you can also access the other languages in the manner you indicated. Though the actual code is likely to be "es_es" rather than "es", but ultimately you can name the languages whatever you want. When outputformatting is on (as it is by default in your templates), then $page->title is a string rather than an object. So if you wanted to grab some other language value, you'd either have to do one of the following: <?php // this $this->user->language = wire('languages')->get("es"); echo $page->title; // or this echo $page->getUnformatted('title')->es; // or this $page->setOutputFormatting(false); echo $page->title->es; I might not be understanding your statement completely, but you'll be able to have a language-native form for the editor regardless of whether the fields themselves are multi-language or not. Field labels and descriptions (the labels that appear with each field in the page editor) are something separate from multi-language fields. I am actually guessing that most people won't even need multi-language fields at all. But if you look in your site tree at the 'Admin' structure, you'll see why we at least needed multi-language title fields for the PW admin. I suspect these multi-language fields will be useful to other people too, especially with web applications or anything that you login to. I've also been thinking we may be able to setup some URL magic to make it switch languages automatically without requiring different pages (like a URL that starts with /es/ but /es/ isn't actually a page in the system). That's beyond the scope of 2.2, but something we may want to strive for in making PW's multi-language support the best out there.

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.