ryan

Horst, that's a good suggestion. I have gone ahead and added this additional check. I guess the thought was that if there was going to be a fail, it would have happened before it reached this point. But that's not a good assumption to make, so I think your suggestion definitely makes sense.

The parent_id and template_id are one way to go, but you could instead use 'findPagesSelector'. You can set this to a Field object, or you can set it to an InputfieldPageAutocomplete instance, like this: $f = $this->modules->get('InputfieldPageAutocomplete'); $f->label = 'Exclude in pages'; $f->attr('name', 'exclude_pages'); $f->attr('value', $this->exclude_pages); $selector = "parent_id=1, template!=admin"; foreach($this->exclude_tpls as $name) { $selector .= "|$name"; } // example: parent_id=1, template!=admin|this|that|whatever $f->findPagesSelector = $selector;

In order to get the page being edited, you would want to hook into something like "ProcessPageEdit::execute" and ask it for the page being edited from its getPage() method, i.e. public function init() { $this->addHookAfter('ProcessPageEdit::execute', $this, 'editPage'); } public function editPage(HookEvent $event) { $page = $event->object->getPage(); // $page is the page being edited } Another thing I want to mention is that it looks like you are doing a lot with facebook on every single request. Maybe that is necessary, but if it isn't, you might want to look into only init'ing the facebook stuff when certain conditions are met. I don't know what those conditions would be in your case, but just bringing it up. In such a case, you may find it helpful to move most (or all) of your init() code into a ready() function. That ready() function is called automatically when the being being rendered is known, so you could do things like this: public function ready() { if($this->page->template == 'admin') { // initialize facebook code } }

That's good to know how Joomla is doing it. Thanks for looking into it. Having to rely on a <base> tag is something I'd want to avoid for ProcessWire (on the front-end), but I'm fine if that's how TinyMCE does it in its own iframe. So I will definitely look into document_base_url setting to see what we can learn from it. No doubt we'll still have to do some kind of replacement tactic. But if we can reduce the number of places we need to do it, that's a good thing.

You don't need to change it of course, but I just was confused by the label so wanted to mention it. I was getting the profiles mixed up. I thought the one you posted was an upgrade to the last, but now I see it's something different. Might be good to see this one on modules.processwire.com too, because I think your new one is more in line with what people look for in site profiles. Though both are obviously useful for different reasons.

Does it swap in the actual directory at runtime? Meaning, if you click the "HTML" button in TinyMCE, do you see the correct URL rather than the relative one? Ultimately though, if they are storing a directory that is a placeholder it's the same problem in that the content lacks portability. But it at least sounds more portable. Handling directories for files/images is one thing, because the URL has common elements for all of them. But handling URLs to other pages is another matter.

Media Temple isn't still using MySQL 4.1 are they? I thought they finally switched to 5 about a year ago. I had a client there that was using a legacy application that was not MySQL 5 compatible. Media Temple's little "change" broke their entire site. I had to setup a MySQL 4.1 server for them elsewhere just to bring it back.

That syntax was not intentional. I'm glad to hear it works, though I worry if there are any side effects. For example, it seems like $p would still have the original ID of /my-page/.

I'm not up-to-speed enough on Google Maps to be able to troubleshoot very well. But if it stopped working on its own without there being some change somewhere, then it's got to be related to a change at Google Maps? Still, you might want to put a console.log(poi_id) and console.log(poicolor) in there to monitor and isolate what's going on. It would be nice to know specifically where the info is getting lost.

I noticed that this is only half of the blog profile. It looks like this is actually the default site profile with the blog profile templates. This could be problematic, because this is a mashup of two different profiles that weren't meant to go together. To be honest, I'm surprised that anything works at all. I suspect that this has got to be the problem.

This can happen if you have the site on a PHP 5.3+ system, and then migrate to an older PHP 5.2 system. We use blowfish hashing for much better security when we can, but only PHP 5.3+ supports it. This is one reason why we're dropping PHP 5.2 support in PW 2.4.

Great update!

Joss, really nice job with this profile! Tested out here and all is working great. Seems like an excellent starting point for people to use ProcessWire and Bootstrap. Admittedly, I had a little confusion with the other BootWire profile because it was perhaps too minimal to the point where I wasn't sure if it was working, or what to do with it next… perhaps that's because I'm not experienced with Bootstrap. But this new version of the profile is great because someone can literally start using it and populating content and photos immediately. It also looks and flows nicely. A couple suggestions: In /site/templates/includes/functions.inc it looks like some of the indentation was lost, which made it a bit hard to tell where a function starts and ends. Though it's possible it's my editor. The front-end could really use an "edit" link of some sort: if($page->editable()) echo "<a href='{$config->urls->admin}page/edit/?id=$page->id'>Edit this page</a>"; Lastly, this is very minor, but I'm still a little confused by the label "Content Management" in the admin. Wondering if it might better be called "Shared Content" or "Tools" or something... because everything in the admin is content management, isn't it? Is the version on modules.processwire.com and GitHub up-to-date with this one you've posted here?

The language translation files are considered part of the site's files rather than ProcessWire's core files, so they have to live in /site/assets/files/.../ rather than anywhere else. I suppose you could always make a symlink to set them up somewhere else. But I wouldn't bother with that unless it's creating an obstacle to have them the way they are.

Can you provide more detail, I'm not sure I understand the question? How are you trying to insert a subject line, from PHP or Javascript or predefined in the field? Also, this should probably be in the Form Builder board, but I see you don't have access to it. I'll be happy to add you to it, but I'm not sure which Form Builder order is yours? Let me know so I can get you properly setup in the system.

I'm making guesses here, since I've not worked with Facebook's API. But it looks to me like the $facebook->getUser() call only occurs after a page is saved? Since it's redirecting to facebook and then redirecting back, there are two requests involved here. The $facebook->getUser() call here would not execute except before redirecting to facebook. What you might want to do set something in $session to tell the next pageview that you want to get that facebook user. So before your $this->session->redirect($loginUrl), you might have: $this->session->hello_facebook = 1; Then in your module's init() function: if($this->session->hello_facebook) { $this->session->remove('hello_facebook'); $user = $facebook->getUser(); }

Looks it it's a bug. Thanks for finding it. This has been fixed in the latest commit to the dev branch.

This feature is not currently on the roadmap, but I would guess someone will develop this as a module at some point. When it comes to core stuff, we really try and focus on stuff that would be used most of the time, and leave occasional use things mostly to modules.

I think we had a bug related to this awhile back. It should be fixed in 2.3. But for now this might work: $field->collapsed = $field->attr('checked') ? Inputfield::collapsedYes : Inputfield::collapsedNo; Thanks for your work with this module. When you get a chance, please add to the modules.processwire.com directory.

Thanks guys. I'm someone that likes to think a lot before I respond to questions, and didn't have time to do that here (it was a Skype interview rather than by email or something). But I'm happy with how it worked out. And perhaps the "live" nature makes for a more interesting interview. Very appreciative to Mike for inviting me to do this. I'm really liking the huge ProcessWire logo at cmscritic.com too.

The only way I know to do it is: Replace the static URL in the HTML before it gets saved to DB with a placeholder that gets resolved at runtime, like "{root-url}site/assets/files/123/file.jpg", where the {root-url} portion gets replaced with $config->urls->root at runtime. This is essentially what PageLinkAbstractor does. The only problem with this is that it creates a dependency of the text/html on the Fieldtype. If someone converts it to another field, or exports/imports to another system, etc., then it'll be broken. Maybe that's okay, but not ideal.

You mentioned "as a normal image field" -- does that mean you are getting the same behavior with a normal (non custom) image field? What happens if you change the sort order of the images or the repeater, is that saved? Does it work outside of a repeater? What version of ProcessWire? Sorry for all the questions, just trying to figure out what the issue might be.

The logic you've got there seems to make sense to me. One thing to note about this sort of counter is that it would not work if you had page caching enabled. But so long as you don't, it should be fine.

Jennifer– This is a fantastic site. This makes me proud! Really great work.

From this page on php.net: So for objects === has got to be faster because it only has to compare one thing (memory location). Whereas, == compares lots of things. So I think that === is what you want when comparing two pages to see if they are the same. Most of the time this works perfectly. But there are some situations where that could fail. An example would be if you loaded a page $a, saved page $b, then loaded another copy of page $a, which we will call $c. If you compared $a === $c, it would fail because you'd saved $b. Why? Any time you save a page it clears the memory cache. So while this seems like an unlikely situation, it can happen. As a result, it's technically more reliable to compare pages by their ID property, like: $a->id == $c->id would still work in situations when "$a === $c" wouldn't. You can also do "$a" == "$c", which is the same as comparing the id property. This works in ProcessWire since the string value of any page is its ID.