ryan

Actually the author is a native database field, so no text searches are necessary. I've not performed this particular search before, but I think that this find below would work. The $user variable can either be a User object or a user ID number. So the following would find all pages created by the user viewing the page: $matches = $pages->find("created_users_id=$user"); So if you were getting the user's name from the URL segment, you might do it like this: <?php if($input->urlSegment1) { $user = $users->get($input->urlSegment1); if($user->id) { $matches = $pages->find("created_users_id=$user"); echo $matches->render(); // or however you want to output the pages } }

Digitex, you shouldn't feel bad about this and you shouldn't say that you failed. Creating things like custom availability/inventory management systems, custom booking engines, and property management tools are very programming oriented tasks. If you are wanting to do something that is by nature a very programming oriented task, and you are not a programmer, then it's going to be a challenge. While I'm certain you could figure it out with enough time, you always have to compare that relative to your own time and budget. I suggest it would be good to hire a programmer to build this for your client. Or, you may be able to find an existing web service or system that can be adapted to your needs. But chances are that it ultimately comes down to putting in the time to code it the way you and your client want it. I would offer to help you more in this regard except that I'm under a non-compete agreement that crosses over with the tools you are wanting to build. However, there may be others here that you could hire to help build this.

That's odd how TinyMCE is modifying the code and adding a data attribute to the object tag, among other things. I've looked around a bit, but don't have an answer as to why it's doing that. Clearly it seems to think it's a 'feature' based on the intentional modifications it's making, but not a very desirable feature. I would suggest making making your own tag for your videos, something like this in it's own paragraph in your TinyMCE editor: youtube:url i.e. youtube:https://www.youtube.com/v/by8oyJztzwo?version=3&hl=en_US Then in your output code, perform a replace to insert the object/embed codes: <?php if(strpos($page->body, '<p>youtube:') !== false) { $replacement = '<object width="420" height="315"><param name="movie" value="$1"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="$1" type="application/x-shockwave-flash" width="420" height="315" allowscriptaccess="always" allowfullscreen="true"></embed></object>'; $page->body = preg_replace('{^<p>youtube:\s*(http://[^\s<]+)\s*</p>\s*$}m', $replacement, $page->body); } // now your $page->body ready to output somewhere

Hmm, that's interesting that it says there were no changes. Can you check your images field and make sure that you haven't defined a maximum number of files for it? Also, can you attach one of the non-working images, just in case there is something about the images themselves. Lastly, just to confirm, you have no image/file upload capability at present?

Thanks for including ProcessWire in your review Selfthinker. I'm glad that it made your top 7! I was confused a couple points though: I appreciate the comparison to Drupal, as I have a lot of respect for Drupal. I want to mention that, at least from my perspective, ProcessWire's template concept is the opposite of Drupal's. Drupal is a markup generator with predefined template files that act as containers for markup generated by numerous other modules. You can think of Drupal's template approach as more of a theme system where you are directing where things should go, rather than actually creating them. And those things aren't necessarily fields, but markup from other modules. You don't have full markup control in any straightforward fashion. This is a plus or a minus, depending on your philosophy and needs. It's a plus in that one can make a lot of presumptions about the output and thus make it themeable. It's a minus in that you have far less control over your output. ProcessWire is built to take the opposite approach. It has no predefined templates and you can take your templates in whatever direction you want. Templates can output markup, but they can also be controllers, web services, connections to other applications and more. The template system uses an API approach where your template file is given API objects that you then decide how to use. One of the API objects ($page) contains information for the page that generated the request. This is the opposite of a theme system because there isn't any predefined markup to theme (except a helper module like MarkupPagerNav). Likewise, your template isn't given fields per se, but it's given objects that you can pull data from. What data you decide to pull is up to you. But you have full responsibility for the output in ProcessWire. Of the CMSs I've used, PW's template system has the most in common with Expression Engine's in a big picture sense, but it's still quite different when it gets down to actually coding templates. Can you elaborate on this? I absolutely agree regarding Drupal (though know a Drupal expert would not). But there is nothing fixed about ProcessWire's template files, and I absolutely think ProcessWire's template system is the most flexible system out there. In PW, your template files have the entire ProcessWire API and all of PHP's environment and function library available. A template file can pull and manipulate data from anywhere in your site. A template file can be a controller, can bootstrap other applications, can act as web services or pull from other web services, can render any other page in the site, can handle URL segments and page numbers... and that's just scratching the surface. ProcessWire's template system is specifically designed for flexibility at it's core. I don't believe there is more flexible system available on any CMS in the world. But if there is something more flexible, I want to know about it. To be themeable, a platform must be a markup generator. ProcessWire is specifically designed to not be a markup generator. Themes are the opposite of what ProcessWire is all about. That's not to say that someone couldn't build some reusable site profiles and make them themeable (PW's admin is an example). Or even call site profiles themes as one might in EE. But I want to clarify that one should never expect ProcessWire to have a concept of themes because that is the territory ProcesWire has no crossover with. ProcessWire is a precise tool like a needle, whereas markup generating CMSs with a theme system are more like an ax. Different tools for different audiences and needs. ProcessWire is very minimal in it's presentation from the admin side, and I think this makes some think that there is more space to fill or that it is somehow unfinished. The reality is that PW is designed for large scale use on sites with thousands of pages. When working on sites of this scale, things like dashboards, sidebars, icons, lines and other graphic flourishes become visual clutter. So ProcessWire's default admin theme is really built around minimalism for scalability sake. That approach might seem barren (or refreshing, depending on your point of view) relative to something like WordPress. But I think it's also something that differentiates ProcessWire in a positive way. And one can expect the same simplicity and ease of use regardless of scale. When you are working on a site with 5k+ pages, you don't want anything else getting in your way. ProcessWire is a tool focused on the job and nothing else. Not because it's unfinished, but because that's the intention. Though PW's admin is actually themeable, and you are not alone in your visual preferences so I think others are doing a good job of giving PW a different look and feel for those that desire it. We are talking about PW's admin interface and not ProcessWire itself (which is defined by it's API). There is nothing about ProcessWire that requires javascript to use other than the admin interface. The admin interface requires javascript for the same reasons that tools like TinyMCE and Google Maps do. PW's admin is a PHP application, but it's also a javascript one... a mostly javascript app according to Ohoh. I think it's appropriate in an application environment to require javascript. Where I think it's inappropriate to require javascript on a web site designed to be accessible (and all sites I build are designed to be accessible). If there were any demand for non-JS support, it would certainly be easy to accomplish (minus TinyMCE), but I don't believe there will ever be enough demand for this to be practical.

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.