Jan Romero

When you put a page field inside a repeater, the $page variable that field gets is the page you’re editing. Not the repeater page the field actually belongs to. Put another way, the $page variable will be the same as $repeateritem->getForPage(). What you want, however, is $repeateritem itself. Honestly, I doubt this is possible out of the box. Like you said, if you used “real” pages in a PageTable field, you would edit those pages in a modal window. I. e. the $page variable supplied to the page field’s custom select code would be the current PageTable item. I don’t want to be the guy who misses the point and answers “why don’t you just do something else”, but PageTables are so much cooler than repeaters anyway. Any specific problems that stop you from using those?

What Ryan described earlier in this thread sounds like exactly what you want? You get a text input where you can just write whatever (thus “free” tagging). That way you don’t need to create pages, but your tags are of course more prone to typos and you have to use urlSegments or GET parameters to show matching pages.

If you have created your own ProcessModule for this, you can add the “permission” property to its module info. Only users with the set permission will load the module. The admin page will be hidden for everyone else. You can also set up your module so that it creates the permission on installation, and automatically removes it when it is uninstalled.

$config->ajax uses $_SERVER['HTTP_X_REQUESTED_WITH'], which isn’t sent with JSONP requests. You can just check for $input->get->callback on the server side to determine if it’s a JSONP request.

Yes, that should be fine. Even if $infoBox had multiple children, this should work and give you the first child. Perhaps the problem lies somewhere in the structure of your function. Would you mind posting the complete function? Is there anything else you do with the $child variable? By the way, the links on your site seem to work right now?

Seems like the translation JSON is corrupted. Under Languages->Français, can you click on the json file you’re trying to use and verify that the first two properties, file and textdomain are present and correct? It should look like this: {"file":"site\/templates\/theCoolestTemplate.php","textdomain":"site--templates--thecoolesttemplate-php","translations":[…]}

I’m not exactly sure if that’s what you want, but if you just want to generate a bunch of nested <ul>s, you should recursively travel around the page tree. Something like: function siteMap(Page $root) { $out = "<li>{$root->title}"; if ($root->hasChildren) { $out .= '<ul>'; foreach($root->children() as $child) { $out .= siteMap($child); } $out .= '</ul>'; } $out .= '</li>'; return $out; } Uuuuh… at least I think that should work. Untested It should give you the complete branch starting at whatever you plug into $root. edit: Actually. Something is bound to be wrong with this. And you need to supply the outer <ul> yourself. edit: Tested it. Fixed it because it was stupid.

Ah. You’re overriding ProcessWire’s $user variable here: $user = $sanitizer->username($input->post->user); Now $user is just some string the visitor entered, and no longer the special user object. Just use a different variable like $username or something. The same thing applies for other API variables like $page, $pages, $session, etc. as well, of course.

Indeed. Without really looking into it, the Javascript must depend on the position of the buttons. Try this to insert the buttons inside .InputfieldPageTableContainer: public function PageTableRender($event) { $return = $event->return; $from = strpos($return, "<div class='InputfieldPageTableButtons"); $to = strpos($return, "</button></span></div>", $from); $buttons = substr($return, $from, $to-$from) . "</button></span></div>"; $insertAt = strpos($return, "<table class='AdminDataTable AdminDataList'>"); $event->return = substr_replace($return, $buttons, $insertAt, 0); } Instead of this hackish string trickery, perhaps a better way to clone/move the buttons would be to use Javascript in the first place. I’m not sure how to best pull that off. Just append a script tag to $event->return?

There is probably a more robust way to do this, but, uh, I tried $this->addHookAfter('InputfieldPageTable::render', $this, 'PageTableRender'); public function PageTableRender($event) { $return = $event->return; $from = strrpos($return, "<div class='InputfieldPageTableButtons"); $to = strrpos($return, "</button></span></div>", $from); $buttons = substr($return, $from, $to-$from) . "</button></span></div>"; $event->return = $buttons . $event->return; } The Inputfield’s original render method puts the button html in the variable $btn, but I suppose there’s no way to just access that one. Another way to duplicate the button elements would be to just copy the code that generates them.

Interesting approach to tagging You’re trying to specify the parent by name, but I’m pretty sure ProcessWire would much rather have a page ID or a path (meaning, wrapped with forward slashes). Because PW can tell “genre” is not numeric (so not an ID), it treats it like a path, as if the slashes were there, but there are no tags under “/genre/”. They’re under “/tags/genre/”. So try that and it should work. Alternatively, specify that you’re selecting by name: $genres = $track->tags->find("parent.name=genre"); I can see how this can seem confusing, because when if you were looking for a direct child of the homepage, it would work. In that case, the path is the same as the name with slashes. Because you’re not really selecting “dynamic” pages here, but rather pages that are a fixed part of your site’s structure, you might want to use IDs instead. That way, if you later want to change a page name/path, you can do it comfortably in the admin, and don’t have to go around fixing your selectors.

(I said “the following readme” because I was going to paste it until I saw your edit) By the way, if you use a template without a file, pages using that template will show the 404 page automatically. You should probably look into what’s causing the error in /about/’s template.

Check out the folder called “errors” in your template directory. You’ll find 500.html and a readme.txt. This html file will be displayed when a fatal error occurs, and you can customize it. To manually cause the 404 page to show, you can throw this exception in your template code: throw new Wire404Exception(); However, it sounds like this recipe might suit your needs better than a 404 error page: First child redirect on ProcessWire Recipes. It’s just a single line: if($page->numChildren) $session->redirect($page->child()->url); die();

If you don’t set a template file, the URL will show the 404 page, as if the page didn’t exist. Logged in users would still be able to view the page’s content in the admin backend. If you want to have a page with a visible template that can’t be accessed by guest users, you can check if the user is logged in. If not, you throw a 404 Exception. <?php if($user->isLoggedin() != true) { throw new Wire404Exception(); } // normal template code

Behold: http://www.microsoft.com/en-us/download/details.aspx?id=22339 How do you think I use typographic quotes in nearly all my posts

There is no space because you didn’t put one there Why not do $partone . ' ' . $parttwo? Edit: Also, upvote for using a proper ellipse char.

This is a feature of PHP. String literals with double quotes (") will evaluate the variables within. For clarity, you could also enclose the variable in curly brackets ({}) like so: echo "You must be the pride of {$subject_hometown}!"; Only if you use single quotes (') the string will be parsed as-is, and you must use concatenation or other string operations to change it. Note that this means that within single quotes, escape sequences will not work either, so you can’t do the following, even though there are no variables in there: echo '\r'; ---- Added by Nico: More infos: http://stackoverflow.com/questions/10512452/php-using-a-variable-inside-a-double-quotes (and I marked it as solved)

An image is a already separate file from the HTML page, so it will be served independently anyways. You can keep the HTML img tag static and just swap out the image by doing something like this: <img src="/penguin/?of=d00m.jpg" /> <?php if ($input->get->of == 'd00m.jpg') { header("Content-type: image/jpeg"); readfile($page->pics->getRandom()->size(50,50)->url); die(); } Pros: – that url serves a random image every time, no matter how you access it Cons: – the url serves a random image every time, no matter how you access it I’m not really sure how this technique competes against a JS solution, but it’s an approach you can take.

Put "die();" after "echo json_encode($json);"?

Does your problem persist after removing the dependency, logging out and back in again? If I do that, the error is gone. It seems that the error just doesn’t get cleared properly. To fix this right now, you can hack the core. Open the file wire/modules/Process/ProcessProfile/ProcessProfile.module and change the following line: if(count($form->getErrors())) { To this: if(count($form->getErrors(true))) { The argument clears the errors that occurred during form validation. It should be safe. The errors are not used anywhere else as far as I can tell. Instead of hacking the core directly, it’s probably better to use the new multiple-modules feature. Funnily enough, Ryan uses the exact same file as an example in his blog post.

Yeah, I just added a bogus display dependency to my own page field and now I’m pretty sure I’ve screwed my site up the same way as yours I’ll try to track it down tomorrow. Steps to reproduce: Add page field to user template (works) Enable it for profile editing (works) Set a dependency (Profile not saved error) To confirm what you’ve already said, removing the dependency doesn’t work. Even removing the field from the template, clearing all values doesn’t work. Neither does re-adding the field. Pretty nasty, this.

“Profile not saved” usually happens when you have invalid input in one of your fields. I can assure you that adding fields to the user template as well as letting users edit them from their profiles works fine. Even with page-select fields. Unfortunately, it working well makes it hard for us to reproduce your error, and it’s hard to debug it over the internet with such a vague error message. I’m sure it will get solved in time. Can you tell us exactly what fields you added and how they’re configured? Also, perhaps looking at the current values of these fields on the database might give you a clue?

You don’t have to get all pages in one go. Just keep it simple. LostKobrakai is showing a good solution where he looks at each design principle and only gets the pages that belong to it. I would like to suggest one minor improvement: Before you build the markup, you should check whether you actually found some pages. You might come across an empty category with no links, which might look awkward. Also, when you put a hyphen before the reading time, it makes it look like a negative number. Try ' &endash; ' or '&emdash;'. Those are the – much nicer looking – dashes I’m using here. To answer your follow up question, look at how LostKobrakai handles all design principles individually, by putting each one into the variable $category one after the other. What you want to find are readings that have the current $category page as their design principle, not the previous. Try this: "template=readings, design_principle=$category"

If you find() a limited number of pages anyway, it probably won’t get any more performant than getTotal(), at least without venturing into hacky territory or cache-like approaches like LostKobrakai’s suggestion. In this case, the PageArray returned from find() already has the total count ready for you, because it uses MySQL’s SQL_CALC_FOUND_ROWS by default! In fact, you can influence this by passing an options array to find() that recognizes the following keys: /*@param array $options - findOne: boolean - apply optimizations for finding a single page and include pages with 'hidden' status (default: false) - getTotal: boolean - whether to set returning PageArray's "total" property (default: true except when findOne=true) - loadPages: boolean - whether to populate the returned PageArray with found pages (default: true). The only reason why you'd want to change this to false would be if you only needed the count details from the PageArray: getTotal(), getStart(), getLimit, etc. This is intended as an optimization for Pages::count(). - caller: string - optional name of calling function, for debugging purposes, i.e. pages.count*/ As you can see, if you do a find(), you get the “numTotal” property for free, and if you just want the number of pages without fetching the actual page objects, $pages->count() will do an SQL COUNT with little overhead. If you want to squeeze performance out of your site, this is probably one of the less worthwhile places to start. edit: by the way, you can see the numTotal property of your PageArrays by var_dump()ing them. It’s one of the first properties it lists.

The third forum down is literally called wishlist It has been suggested before to default to the German umlauts, which won’t happen because plenty other languages use ä, ö, ü, and they use the normal trema-less characters instead of the German -e combinations. Not sure why ß isn’t in there, though.