ryan

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.

Theoretically, the more specific you can be with a query, the more potential there is for it to use the best index and locate things faster. But if there aren't other templates using the field you are finding anyway, then it's also possible it could add overhead (though probably not measurable). But like I said, I think more specificity is better overall. Anything you can specify from a selector in terms of finding pages should ultimately be using an index in the DB, except for keywords in %= queries.

This is something that we will most likely be adding soon. This would be a little trickier, as these inputs come from ProcessWire Inputfields rather than FormBuilder. Though I'll keep thinking about alternatives. One alternative is that it's always possible to clone an existing Inputfield, rename it, and place it in your /site/modules/. Install and modify it to produce your preferred output. Assuming I understand correctly, we already have this. But you might have to be on the dev branch. I may lead the project, but we have several core team members already. All the commits still go through my account (for QA), but I'm not always the one coming up with what's in the core. I agree, and I think the Concrete5 marketplace is a good model for us.

It sounds like $user isn't in scope. When you are developing stuff like this, it's good to enable $config->debug=true; in your /site/config.php file. That way, PHP should report notices like this. This is probably what you want: $user = wire('user'); if(!$user->language->isDefault()) $segment = $user->language->name; else $segment = '';

The answer is both Inputfields and Fieldtypes, but they are validating in totally different contexts. Inputfields validate user input. Fieldtypes validate data set to a $page, regardless of where it comes from. Think of Fieldtypes as API-side type validation, and Inputfields as interactive/user-input validation. Here's more detail: Inputfields only come into play when there's interactivity, i.e. a form and a user inputting something. Input should be validated by Inputfields so that the data is valid enough to echo back to the user, or for something else to pull the value from it. Inputfields should always be validated server-side where appropriate, but can also optionally include client-side validation. Inputfields can be used separately from Fieldtypes (they are used throughout ProcessWire in all forms). If there is some kind of input validation that isn't specific to a page or fieldtype, then it should be done by the Inputfield. Meaning, most validation responsibility goes with the Inputfield and an Inputfield shouldn't assume there's going to be any more validation beyond it. Inputfield sanitization/validation is done in $inputfield->processInput() or $inputfield->setAttribute('value', ...). The processInput() method is the first line of defense for values coming directly from a form. Whereas the setAttribute('value', ...) will see values sent from the form as well as values sent from the API to the $inputfield, like an $inputfield->attr('value', 'some value'), call. Where you put your sanitization/validation depends on what you are trying to account for. You may see some Inputfields have a setAttributeValue() function. This is not part of the Inputfield interface. It's just a methodology I sometimes use to isolate setAttribute('value', ...) for more readable code. Inputfields report errors by calling $this->error('error message'); The user will see that error message within the context of the field. Fieldtypes come into play every time a value is populated to a page. This could be from the API, the core, modules, importers, Inputfields… really anything. They need to validate that the value sent to the page is consistent with the type of data the Fieldtype is responsible for (type validation). So if the Fieldtype only stores a string, then it needs to make sure it's a string. If you set something invalid to a $page, the Fieldtype needs to either convert it to be something valid or if it can't, throw it out. For the most part, they should do it as quickly and silently as possible, because they get such a high volume of traffic. Not to mention, Fieldtypes can't assume there's a user present to see anything. Fieldtype sanitization/validation is performed by $fieldtype->sanitizeValue(). Every value set to a $page gets routed through that function, for the appropriate fieldtype. Whatever you do in there needs to be fast. That would be the correct behavior for the Fieldtype, but not for the Inputfield. The scope for Inputfields goes beyond just pages. They don't know what they are being used for. If they did, then their usefulness would be much less. But that's just "in general". There are some cases where you are building a Page-dependent Inputfield and your Inputfield needs to know about the $page being edited. Core examples would Inputfields related to files and repeaters. In that case, make your Fieldtype pass it along to the Inputfield. Each Fieldtype has a getInputfield() method that gets a copy of the $page and $field being edited. It has to return the appropriate Inputfield to edit the provided data. So you can easily send it along to the Inputfield right from there: public function getInputfield($page, $field) { $inputfield = wire('modules')->get('InputfieldSomething'); $inputfield->set('editPage', $page); // inputfield now has a $this->editPage property return $inputfield; } They can report error conditions, but technically they aren't the place for it. Yes. In general, Fieldtypes can't assume there's anyone there to see an error. But if you have some need where you think it is necessary to do from the Fieldtype, try $this->error('message') … it will only be seen in an interactive context. If you want to report an API error, throw an Exception. But if you can keep all of your error reporting in the Inputfield, that is the right place for it.

I agree, we need a directory. I will get around to building it eventually. But if anyone else is interested in taking on this project, just let me know.

Disabling CSRF protection like in the link Pete provided is one way to do it. But if you want to maintain CSRF protection, a better way to go might be to just setup an email filter so that those messages go to your trash automatically. But I will go ahead and add a CSRF specific Exception class to 2.3 so that you can use catch to modify the behavior.

Seems like a good idea! ProcessWire caches a lot of this stuff behind the scenes. Once a page is loaded, it doesn't reload it unless the memory cache gets cleared. Likewise, results of selector queries are cached as well. So the navigation tree would have to be pretty large before preloading would help much. But it is feasible to do. It would mean SQL querying the pages_parents table and pulling out all IDs, then preloading those pages with $pages->getById(array(ids...)). But I'm not sure it would amount to a measurable difference or not.

I think that's a question for Joss, but before he'd asked me to put it in the "discussion" tab of the page. But because nobody really gets notified of changes in there, maybe posting in the forum would be better. What do you think Joss? You might have noticed I still need to update the design for modules.processwire.com. There just isn't enough time in the day. Hopefully soon!

Is it a shared hosting account, or a dedicated/vps? If it's some kind of dedicated platform where you don't have other accounts under someone else's control, then it's not as much of a concern. But I think this is a question for your hosting provider. What's probably happening is that PHP can't write to /site/assets/. Who is listed as the directory owner? It's most likely you, which would mean that Apache is running under an account other than yours that does not have write access. I would check with your hosting provider to see what permissions they recommend for CMSs that need to have a writable directory. This can very from host to host, so it's tough for us to narrow in on it here short of trying different options (that are more secure than 777) till it works.