ryan

Line 318 seems to imply that the page being accessed didn't yet have a template assigned to it. That sounds like a core error rather than a user one, so I'd be curious about how to duplicate that–maybe a potential bug. But if it was accompanied by a nesting level issue (via xdebug), and correcting the xdebug setting also corrected the issue, then I wouldn't worry about it. Are you still getting the Page.php line 318 error?

I agree with Teppo and this is the same method the core uses.

I have no idea why users are getting logged out in your case, but a few things I would look at: 1. How long was the user logged in at your site? Make sure they have completed at least one full page request as a logged in user before you redirect them elsewhere. You can accomplish this by redirecting to a local page first before redirecting to another site. 2. What URL does your payment gateway return them to? If the user started out on an http URL and returned on an https URL (or the reverse), that might be something to look at. What sort of switching between http and https does your site perform? 3. Is the user returning to the exact same hostname? i.e. www.domain.com and not domain.com ?

Also try enabling debug mode in your /site/config.php and look at the Debug link at the bottom of the admin theme. There is a list of all loaded modules (among other things). If you want to see how it's getting that from the code side, then have a look in /wire/templates-admin/debug.inc.

Another option would be to add a small module that hooks Page::render and replaces the paths directly in the output... when running on localhost. It could replace it with something like this: public function init() { if(wire('config')->httpHost == 'localhost') { $this->addHook('Page::render', $this, 'hookAfterPageRender'); } } public function hookAfterPageRender($event) { $event->return = str_replace('/site/assets/files/', 'http://domain.com/site/assets/files/', $event->return); }

Sounds like a good idea. What is the use case? Wondering if would be better provided as a data attribute or something along those lines.

The blog profile is also a good demonstration of how to implement tags.

Adrian, remember to restore the output formatting state of $user, i.e. $user->of(true); unless you sure you won't be outputting anything from user after that block of code. But safer just to restore it to of(true) after you've saved.

What version of PW? Are you sure that category is a field of type "Page" ? Does it work if you change it to this? if($input->urlSegment1) { $name = $sanitizer->pageName($input->urlSegment1); // remember to sanitize $category = $pages->get("template=category, name=$name"); $results = $pages->find("parent=$page, limit=10, category=$category, sort=-date"); } Also, just want to double check that you intend for the parent to be $page in that selector? That would mean your articles and category URL segments are sharing the same namespace. That's perfectly fine, but not that common to do that, so just double checking.

I just needed a couple more days to finish writing up the announcement and changes. I'm guessing you've already seen it by now but just in case you haven't it's located here: http://processwire.com/about/news/introducing-processwire-2.4/

I would bet that's got something to do with this line. That line may not be necessary anymore now that we've got CKEditor's ACF working properly. Try commenting it out to see if that fixes the issue? Please let us know.

I'm not sure that I understand, but you should have full control over your field names in FormBuilder. If you want a field to be automatically populated from a GET var, then you'd want that variable name (i.e. "myfield") to be what's specified in the URL, i.e. domain.com/path/to/form/page/?myfield=something. Likewise you'd want to use "myfield" (or whatever you named it) as the field name in FormBuilder. Also you mentioned populating those values programatically. You can do that like this: $vars = array('foo' => 'bar'); echo $forms->embed('myform', $vars); If using it in a non-embedded way (like method C) then you'd just populate the values to your form the old fashioned way, like you would with an Inputfield form.

You'll want to test ahead of time, but I think it'll still work. There are some bugs and security issues in PHP 5.3 versions prior to 5.3.8, which are good reasons for nobody to use those versions. That's the main reason I set 5.3.8 as the minimum. But the reality is that it should still work fine in any 5.3. Chances are it would still work fine in 5.2 as well, but I want to take that monkey off our back so we can move forward.

Nice work mvdesign! Very attractive look and lots of good thinking here. We* are actually working on a second core admin theme option that is quite similar in many ways to the look you've posted here (the overall layout of major elements is very much the same with regard to masthead and sidebar). Once released, I'm imagining it will also serve as a very good starting point for taking your design here to a full admin theme. *I say "We" because I assume I'll be working on it here soon too, but so far all the work has been done by someone else.

This is already old news to many of you here, but I finished writing up the full announcement today so figured I should post it (click the link below). Numerous upgrades and refinements make ProcessWire 2.4 our most friendly and powerful version yet! ProcessWire 2.4 is focused on listening to the feedback from of our users and answering with the best CMS experience for web designers/developers and their clients. Read the full announcement. For those upgrading from a previous version of ProcessWire, please read all of the upgrade instructions. Hope that you enjoy this new version! A huge thanks to Avoine for sponsoring the Field Dependencies feature new to ProcessWire 2.4!

Any difference if you remove the 3 validations you mentioned? I'm curious if it's an issue of validations or lower level.

InputfieldWrapper is the base class for a Form, Fieldset or Tab (InputfieldForm, InputfieldFieldset, etc.) It implies an Inputfield thats purpose is to contain other Inputfields. While Forms, Fieldsets and Tabs represent specific things, a regular InputfieldWrapper just acts as a wrapper/container for Inputfields, without any kind of visual representation. Because it is a type of Inputfield, it can take the place of a single Inputfield, while actually containing many of them.

Using modules for this stuff is nice if you are building functions you'll be re-using on multiple sites. But for the sake of simplicity, I usually put my shared output generation functions just in a common include file like this.

I wasn't able to duplicate the issue that Soma mentioned, despite repeated attempts here. As far as an issue with files in repeaters, I think it's possible there is an issue there, but haven't had time to test that one out yet. I've added a GitHub issue report for that so that I can test that one out during the next debugging phase (aka early Sunday morning).

What's your <input type='file'> code look like? How are you outputting the multiple <input's> for each file? Does your name attribute read 'documents[]' (indicating an array) rather than just 'documents' ?

Klauss, welcome to the forums. I think you might have too broad of a question there, and I'm not sure anyone can tell you how to build your app. I'm not sure what wettransfer is, but I think you'll need to focus more in on how to do these things with PHP and server configuration (4 gb file uploads is going to require some server config). I think you'll find ProcessWire helpful once you have a good idea of how you'll build this app.

You can also use language support and translate any of ProcessWire's built in messages to your own (including default language).

You might look at WillyC's htaccess rules too.

Your solution looks good, but would make the riders always appear at the bottom of the results. Maybe that's okay, but I think riders and other types of pages might be different enough that they'd warrant further segmentation or their own search, perhaps their own tabs at the top of the page, or regular pages in left column, riders in right column, etc.

I have no problem with spaces in passwords. Can't say I've ever thought to put spaces in passwords, but it makes sense. I'll update to support that the next time I'm in the code for that module. As for logging in with email address, PW uses the username as the unique key for all users. Users are pages, so this is for consistency with the pages system as a whole. I think maintaining this consistency is preferable in keeping the whole thing as simple as possible. Not to mention, 'name' is a built-in property of every page, whereas 'email' is just a custom field in the template (it's technically possible for it to not exist).