ryan

Thanks for adding it there Selfthinker. That's interesting that it says PW is mostly written in Javascript. I'm guessing it's getting that from TinyMCE, jQuery and jQuery UI. Collectively the source code length for those 3 things would definitely exceed ProcessWire's. I'm mildly offended that it says "few source code comments" .. but of course, if it's counting all the JS stuff, then it's counting minified JS with comments removed. I bet it would give us more respect for comments if it weren't counting all the JS.

Martin, I haven't yet had my morning coffee so forgive me if I'm missing something. Didn't we have that on the earlier treeMenu variations? http://processwire.com/talk/index.php/topic,128.msg790.html#msg790 (and the one in BDH's most recent post) Also, back before treeMenu, I sometimes used a little jQuery for this. Once you know the current page in the list you can do something kind of like this: $("#subnav li.on_page").parents("li").addClass("on_parent"); Though the jQuery is more of a quick hack, whereas It's probably better to do it in the actual output via something like treeMenu().

Nico, replace your $page->hidden = 'true'; with this: $page->addStatus(Page::statusHidden);

Can you post what's on lines 20 and 21? Or just post the entire code of the function you are using. I'd tested it out here and all worked well. The error message you posted sounds like $img->pagefiles isn't recognized (that's my best guess). Access to that property was added in a Nov 1st commit (less than 2 weeks ago), so you might want to double check the the system you are testing on has a relatively recent version, just in case.

Not yet, but definitely under consideration. I don't know a lot about CKEditor. Are there any advantages to it vs. TinyMCE? I always thought the two were roughly equivalent. ProcessWire 1 used FCKEditor (the one before CKEditor) and it seemed alright, though I'm assuming CKEditor is an improvement.

If it's something you want to commit to the DB, you'll want to make sure that the parent doesn't already have a sortfield specified. If it does, then it's going to sort by that field in the tree automatically, and you'd have to account for that. But you would have had to specifically set a sortfield for that to be the case. By default, pages have a sortfield of 'sort', which just means it will sort by the 'sort' property of the child pages (an integer). That's what you want. In your case, you want to grab the first page and change its 'sort' property to be one less than it currently is, and then take the page you want to insert and give it the 'sort' value that the first page had: <?php // get the parent page you'll be working with $parent = $pages->get('/some/parent/page/with/children/'); // get the first child of $parent $first = $parent->child(); // create a new page that you want to insert (or grab some existing page) $new = new Page(); $new->template = $templates->get('some-template'); $new->parent = $parent; // set its 'sort' property and save it $new->sort = $first->sort; $new->save(); // now save $first with it's sort being 1 less $first->sort--; $first->save(); That should insert the new page as being the second child of the $parent. I also like using date/time fields for sorting, even if you don't need the date/time for anything else.

While it would be nice to have it remember the crop, I agree it's something that isn't technically necessary and probably not a real time saver. But maybe just a nice feature to add in version 2.0 or something. And then in version 3.0, you could add little overlays to the main image to show where the crops are... I'm kidding, but this is just fun stuff to think about. Instead, I think the most value would be in just being able to see the existing crop from the admin without having to go view the page. For example: Display it in the image list below the large image with the existing "thumbnail" label/link above or below it. Or just a simple link to see it, like: "thumbnail: view / change". Or show the crop in the crop editor with the label "your current crop". Could the large images be scaled to the width of the window, or would that break jCrop's ability to track the pixels of the image? I'm guessing it would break jCrop, but just curious. Thanks for posting the screencast too!

Oliver, just got a chance to try this here and I'm really impressed. This seems very polished for an alpha version. Everything worked for me as I thought it would and was very easy and straightforward to use. I don't have any good test cases at the moment so just experimented rather than tested with a real site... But if this works as well in larger scale/real use, it is really a great system you've built. It looks like a lot of work has gone into this and this may the most extensive modules built yet. Thanks for your efforts here and keep up the great work!

Nice work Antti! Just tried it out and all seemed to work well, and I love having this capability! It did take me a couple minutes to understand how it works from the cropping side. For instance, I wasn't sure why the pixels weren't locked when selecting a crop area. But then realized it'll let me crop and scale at the same time (cool!). I had a couple questions/comments: 1. After submitting a crop, the screen that follows just says "Cropped Image: 1" rather than a look at the crop. I'm assuming that's because it's a work in progress, but just wanted to mention it in case I was getting a debug message or something. Though it does appear that the crop did work. 2. Is there any way to get back to the crop? If I click the "thumbnail" link again, I'm starting a new crop rather than seeing the existing one. 3. When making a crop, the crop appears on the left and the large image on the right. I was making a crop of 400px wide, but could only see part of it on the left. I was wondering if maybe the crop should appear below the large (rather than next to it), as I'm thinking I just ran out of screen width? You can add a new function to any other core class or module, just by adding a hook for a function that isn't already there. I would suggest removing the function from Pageimage.php and instead adding it to your FieldtypeCropImage class. I just tested this exact code below and it works exactly the same as if getThumb() was in Pageimage: <?php class FieldtypeCropImage extends FieldtypeImage { public static function getModuleInfo() { return array( 'title' => 'Crop Images', 'version' => 100, 'summary' => 'Field that stores one or more GIF, JPG, or PNG images', ); } public function init() { $this->addHook('Pageimage::getThumb', $this, 'getThumb'); } public function getThumb(HookEvent $event) { $thumb = $event->arguments[0]; $prefix = $this->sanitizer->name($thumb); $img = $event->object; $imgPath = $img->pagefiles->path . $prefix . "_" . $img->basename; $imgUrl = $img->pagefiles->url . $prefix . "_" . $img->basename; if(is_file($imgPath)) { $event->return = $imgUrl; } else { $event->return = false; } } } So the above adds a getThumb() function to the Pageimage class without you having to hack the core to add it. The behavior of it from the API side is identical, so you don't have to change anything else. Great work with this new fieldtype! I look forward to using it.

It will provide multiple inputs for each language, like in that screenshot. But the thing to watch out for here is that access $page->title will output the proper version for that language. This is not desirable for SEO. So if you use these multilanguage fields, you'll want to be sure to have some language trigger in the URL itself. That way Google and other search engines can index both language versions. <?php // note I updated your code example if($input->urlSegment1) { $language = $languages->get($input->urlSegment1); if($language->id) $user->language = $language; } Yes, this will be fine to do. But maintaining the language state will be a pain. You'll have to remember to include that language urlSegment in all of your href attributes where applicable. It would be much easier to remember the language just as a $session variable, but of course that would not be SEO friendly. That's why I'd like to implement a placeholder (non-page) URL segment at the beginning that PW will know to use as a language trigger, like /es/path/to/page/. Still, that won't allow multi-language URL paths, but maybe an okay tradeoff. Ultimately a multi tree approach solves any possible issue on the front-end. And that's why I think most people will still take that approach for multi-language sites on the front-end. But at least we'll have a couple different ways that people can achieve multi language sites.

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.