ryan

You could also do this: $events = $page->siblings->remove($page)->slice(0,3); but this may be better: $events = $page->siblings("id!=$page, limit=3");

Technically you don't have to, as PW already has already sanitized the URL segments. But I think it's a good habit to sanitize anything is considered user input (as a URL segment would be). So rather than having to remember what you do or don't have to sanitize, I suggest just maintaining the habit of sanitizing everything that comes from input. They are not cached. Too many possibilities with GET vars in order to maintain a cache. Of course, you can always maintain your own MarkupCache if you want to. In the template cache options, you'll also see there is an option to make it bypass the cache when certain GET or POST vars are present. Sorry, my mistake. I think that the first part of the expression needs to have parenthesis: if(($value = $sanitizer->name($input->get->type)) && in_array($value, $allowedTypes)) $input->whitelist('type', $value);

You don't need to create a new template for that unless you want to. It uses the default admin template, and the login form is created by the ProcessLogin module. The best place to modify it is probably in your admin theme's custom stylesheet. It's also possible to create a login form anywhere on your site (like on the front-end) and just use the $session API functions to authenticate the user. But if your intention is to create an admin theme, then it's best to let the existing one stay and customize it from the stylesheet.

Just got a chance to test this here. Unfortunately I can't seem to reproduce it though. I tried drag-sorting child pages in both /tester/ and /promos/, but the order is retained regardless of what I try. I'm starting to wonder if we're looking in the wrong place. What web browser and version are you using?

Thanks Landitus--got it. I'll take a look and let you know what I find.

Not sure I totally understand the example, but maybe something like this would do it? $sql = <<< _SQL SELECT pages.id, ref_page.id, field_title.data FROM pages JOIN field_referenced_page AS ref_field ON ref_field.pages_id=pages.id JOIN pages AS ref_page ON ref_field.data=ref_page.id JOIN field_title ON ref_page.id=field_title.pages_id WHERE pages.parent_id={$page->parent->id} GROUP BY ref_page.id _SQL; $a = array(); $result = $db->query($sql); while($row = $result->fetch_row()) { list($id, $ref_id, $ref_title) = $row; $a[$ref_id] = $ref_title; } Written in the browser without data to test on, so it may not be in a working state, but something like this may provide the result you are looking for.

If the users aren't administrative users, then it would be better to keep them on the front-end where you are in full control of any access control scenario. For instance, you could assign access just through a page reference field attached to the user. However, if they are administrative users, you can't currently restrict their access in the manner you've asked without creating a module to hook into the Page::editable and/or Page::viewable functions. This thread has a little more info about doing that, but let me know if I can expand on it:

Not technically a supported feature at present, but I think you can get the result you want. You'd take a query like this: $pages->find("body*=something"); and convert it to this: $pages->find("body.data{$user->language}*=something"); That should return just the pages that match the current user's language, rather than including the default language.

http_build_query is nice. You can also build them yourself if you want. I usually use PW's $input->whitelist() to store values after I've sanitized them. As an added bonus, PW's pagination/pager module knows to include any $input->whitelist() get vars in it's links. So you can have your GET vars persist through pagination. Here's an example where the GET vars get used in a $pages->find() query, and also use them in any links. $allowedTypes = array('item1', 'item3', 'item7'); $allowedSorts = array('title', 'date', '-title', '-date'); if($value = (int) $input->get->region) $input->whitelist('region', $value); if($value = $sanitizer->name($input->get->type) && in_array($value, $allowedTypes)) $input->whitelist('type', $value); if($value = $sanitizer->name($input->get->sort) && in_array($value, $allowedSorts)) $input->whitelist('sort', $value); $selector = "template=something, parent=456, "; $url = "./?"; foreach($input->whitelist as $key => $value) { $selector .= "$key=$value, "; $url = "$key=$value&"; } $url = rtrim($url, '&'); $selector = rtrim($selector, ", "); $results = $pages->find($selector); echo $results->render(); // link to another region but with all other vars the same $region = 123; if($input->whitelist->region) $url2 = str_replace("region={$input->whitelist->region}", "region=$region", $url); else $url2 = $url . "&region=$region"; echo "<a href='$url'>Region</a>";

PW loads stuff on demand, so if you print_r $page, then that's going to trigger it to load a lot of stuff and perhaps even an infinite loop. It's best not to print_r or var_dump $page objects for this reason. A $page object is pretty light in it's default state. It gains weight based on the number of autojoin fields you have. Following that, all fields you access are loaded on demand and then become part of the page's data. To keep pages as lightweight as possible, you'd want to limit your autojoin fields to only those that you need for every instance of a $page (like the 'title' for example). While a $page is intended to be lightweight, it's obviously going to be heavier than just an ID. And by that logic you can store more IDs in memory than you could pages. Though it's rare that I would do so because an ID rarely provides much value on its own. But there are cases, and here's how you can do it. You can query any field_* table and expect that it will have a pages_id field. So if I wanted to find all pages that had the title 'Templates', I could do this: $ids = array(); $result = $db->query("SELECT pages_id FROM field_title WHERE data='Templates'"); while($row = $result->fetch_assoc()) { $ids[] = $row['pages_id']; } // ...if you later want to convert it to Page objects, there is a getById function: $matches = $pages->getById($ids); // returns a PageArray Note that getById function performs faster if it knows what template is used by the page. It is an optional param that can be specified like this: $pages->getById($ids, $template); Here's another scenario. Lets say that you want to do something like a $pages->find(), but get the IDs rather than the Page objects. Here's how you can do that: $finder = new PageFinder(); $query = new Selectors("title=Templates, template=basic-page, sort=-created"); $results = $finder->find($query); // $results is array $ids = array(); foreach($results as $result) { // each result includes: id, templates_id, parent_id and score (if rank sorting) echo "<li>Found Page ID $result[id] using template ID $result[templates_id]</li>'; } That's how you can use the PageFinder class, which isn't part of the public API, but may be useful in certain situations where you only need to interact with IDs. However, keep in mind that when you use this, you are bypassing PW's caching and such. So if you are using this to ultimately generate Page objects then you will likely lose performance by going this route. But if you have a use for thousands of page IDs and don't need to turn them into Page objects, this would be the way to go.

If you want, email or PM me a copy of your database (SQL dump) and I can try to load it here to see what the issue might be. Also, I think it would be worthwhile to grab the latest source code (2.2.0.1) to replace your /wire/ dir with the latest, just in case.

Try changing the last line to this: } while(count($entries) || count($images)); Basically replacing the "&&" (and) with "||" (or). If that doesn't do it, paste in your code so we've got the full context to look at.

Mike can you give us a lot more detail? Are you creating a page in the admin or in the API? If in the API, is this from a template, a module or from a command line script? If you think screenshots would be helpful, please include that too.

I have a feeling that your code was okay, and it was just PHPMailer that was failing... perhaps because one of the options needs to be changed, like SSL or password or something like that. That's why I think getting a look at whatever error message it is producing would probably answer it.

You are right, the picture answers it. Looks like your browser is supplying this auto completion and most likely doesn't trigger the event we're looking for when it does the auto completion. One thing you might try is after letting it populate the auto completion, hit the spacebar or some other key and see if that then makes it populate the URL tag?

Also wanted to add that using $config->styles or $config->scripts on your own site is totally optional, unless you are using some module that requires them (none of the core modules do). They were designed for use by the admin template. I rarely use them myself, but if they suit your needs on the front-end, then no harm in using them.

For a field that can contain multiple images, the value of that field is always going to be a type of array. So you'd have to either check to see if there are any items in the array, or try to retrieve the first time like Soma did. Here's how I usually check if there are any images: if(count($page->images)) { // images here } else { // no images } When it comes to a single image field, you are dealing with just one item that is either set or it isn't (rather than an array). You only need to check if it has a value: if($page->image) { // image here } else { // no image } When you use $pages->find(), $pages->get(), $page->children(), etc., you can also find pages that have a given amount of images. So if you wanted to find pages that don't have any images, you could do this: $pages->find("images.count=0"); ...or pages that have one or more images: $pages->find("images.count>0");

This may not be a safe inclusion because it's not specific enough. It's going to search all of PHP's paths for a "pw" dir before it searches the current dir. So be sure to complete that to a absolute or relative path. Absolute meaning a full "/path/to/pw/index.php" or relative meaning one that starts with a dot, i.e. "./pw/index.php" or "./index.php" or whatever it is relative to your PW installation. Also, for your API call, I suggest using wire('pages')->get() rather than $wire->pages->get().

I recommend starting with another language pack, like this one: And then just replace the existing translations with your own.

I don't have experience with PHPmailer, but would guess that the $mail->Send() is failing, since $success never gets set to true. I think the best bet here is to figure out how to retrieve the error message from PHPmailer, as I think that would likely answer the question. Also want to mention that when you finish this up, be sure to run all the fields in your $form and $required_fields through a sanitizer. Particularly any that can appear in email headers like Subject or From.

Thanks for your interest in making this language pack. While I can't help with translation, just let me know anything else I can do to help.

I have the same wish. But this is a little more complex than it sounds, so has to wait until there's time to do it right. However, shorter term the intention is that one can use an image field in a repeater to achieve something similar.

Nice work Sylvio. Quite an interesting and unique site! Why PW 2.1 and not PW 2.2?

I would consider that an upgrade.

Thanks Robert. It looks like we had a bug where the multi language fields expected you to have more than 1 language before you started using multi-language fields. I fixed this and posted the update per your GitHub report.