ryan

You need to give readfile() the actual server file path rather than the URL: $filename = $pages->get('/some-page/')->file->filename; ... readfile($filename); Also, I think it would be preferable if you could find a way to do this without all the redirects. At least, if switching to $pathname doesn't fully resolve the problem, I would look at the redirects first.

Nikola, I haven't tried this yet, but this may provide what you need by putting this in your template: $controller = new ProcessController(); $controller->setProcessName('ProcessForgotPassword'); echo $controller->execute(); Since it'll be outputting markup, you will have to style it. But I think you already pretty familiar with this considering your beautiful admin themes.

Thanks for the credit Soma! The Omnia is my favorite ProcessWire site. Beautiful hotel too. My Dad apparently knows of this hotel, it must be internationally famous. I stepped through the reservation process the other day, and there is a lot of quality and attention to detail everywhere.

Welcome back Arkster! This actually sounds like your needs fall pretty close in line with what the FormTemplateProcessor module does. I would take a look at that first. It may be a good starting point for what you are trying to do. The Comments field is also a good solution for something like the guestbook, but probably not ideal here since you are wanting to use the same form for RSVP info. In addition, I would probably ask them to enter their name rather than having to maintain codes or separate URLs, etc. At least, we've always had to enter our name on any online wedding RSVP we've ever used. It just seems like extra/unnecessary effort and support burden once you start introducing codes, unique URLs or the like (though that's just an outsiders perspective).

Edit your field (i.e. Setup > Fields > Body). Click on the 'Input' tab, and open the 'TinyMCE advanced settings' fieldset. Add "anchor" to the theme_advanced_buttons1 input, wherever you want it to appear in the buttons. For instance, here is what my entire field value looks like when I append it to the end: formatselect,|,bold,italic,|,bullist,numlist,|,link,unlink,|,image,code,fullscreen,anchor Once you save that setting, your field will now have an anchor button where you can insert anchor links. To link to anchor, you would just click the link button and type in the anchor name preceded by a '#'. For example, if you created an anchor named "processwire", you'd link to "#processwire".

I've taken a look at the phpinfo and noticed the server is not running Apache. Instead it's running something called IdeaWebServer (a server I'm not familiar with). It looks like IdeaWebServer isn't close enough in terms of Apache compatibility. I think there are several potential problems with running on a server that is not 100% compatible with Apache. Beyond just getting it to work in the environment, ProcessWire depends on Apache-specific directives in some areas of security, like blocking access to protected files and directories. The same goes for many other CMSs and web applications. Even if we could get things working here by modifying core files, I would be concerned about long term stability and security in this environment, since it isn't fully Apache compatible. I would switch web hosts if I were you. Still, if you want to keep at it, it looks to me like the problem lies in the RewriteEngine. As soon as there are GET variables present in the URL, it appears that the RewriteEngine gets disabled. For instance: http://alergolog.org/templates/ vs. http://alergolog.org/templates/?id=1 This is not correct behavior for the server's RewriteEngine, and is preventing you from even being able to use the admin. Any idea why IdeaWebServer is disabling the RewriteEngine when GET variables are present? I suspect this behavior would interfere with a lot of applications, so am a little surprised by it. But maybe it's something that your web host can advise on. Please let us know what you find.

Pawel, can you PM us a link to your phpinfo file? I tried alergolog.org/directory/info.php but it wasn't there. Also while we troubleshoot, it would be best to set the index.php back to how it was, just to limit the number if variables here. Lastly, when I go to alergolog.org, I get the ProcessWire default profile homepage. If it is installed in /directory/, it shouldn't be possible for it to display at your site root. Have you moved the installation from the subdirectory to the root? (I'm guessing so from your previous message, but want to confirm). Regarding the last issue you are seeing with an empty page list, please PM me a username/password to login to your admin and I can find out what it is. You might also be able to tell by looking in your javascript console to see if there are any errors. However, like Teppo, I suspect there's something odd going on with the server's rewrite engine, so it would be good to get a look at the phpinfo.

Soma is right, it all comes down to how you code it and where you put your conditionals. Feel free to post your code here and we can have better context to make suggestions.

Despite that number being typecast to a string, it looks like PHP actually typecasts it back to an integer if the string contains only digits, when creating an array index. I found that I could get PHP to keep it as a string if I appended a non-digit character to the end of it (space). I just committed the update, so this issue should be fixed. Since this PHP typecasting behavior is a little unexpected, I'm just hoping the behavior is the same across PHP versions. Let me know if you find there is still an issue.

The audience for making Process modules is small enough that time for documentation is getting put towards broader scope stuff first. I think there might just be 4-5 of us that have an interest in making Process modules. But this will be in the documentation at some point, especially as interest for it grows.

I think this issue here is that 'open' and 'id' aren't meant to be used together. It's meant to be one or the other. When they are both used, you'll get duplication. Maybe there is a use for them to work together, and it could probably be done, but it's not come up as a need yet. Though if someone else has a use for it, I'll be happy to take a closer look to see what might be possible in the future.

Thanks for finding the bug. I was able to reproduce that with a repeater having just an images field, and then dragging in an image. The reason it wasn't working is because no changes to the page were actually made when you hit save. The changes were made before that via ajax (where the image was added). As a result, InputfieldRepeater didn't know to publish the item. I have fixed this and just pushed in the latest commit. Can you confirm that it fixes it on your end too? There was a JS update as well, and I forgot to update the module version, so you may need to hit 'reload' in your browser the first time you edit the page, just to be sure the new JS loads. For the google maps field, are you talking about FieldtypeMapMarker? I wasn't sure, because there was another one made a long time ago that I think was literally called GoogleMaps. Just wanted to be sure I had the right one.

Process is just an abstract module designed for extending. Its behavior is pretty simple in that it calls a method in the module matching the first URL segment. If there is a URL segment, it calls execute[urlSegment] in your Process module (if it exists), with the first character of the url segment in uppercase. For example, if your URL segment was "new", it would call executeNew(). If there is no URL segment, then it just calls execute(). So it is just a basic mapping of URL segments to methods with execute() being the default. I suppose this is kind of similar to code igniter except for the naming (with execute… being part of it) and PW doesn't pass any arguments to the execute() functions... rather you can retrieve them from $input->urlSegment($n) if you want them. All of those execute[?] methods just return the content (markup) to be output. It is output directly in the #content div of the admin template. Unless the call was initiated by ajax, in which case just your output is sent (without the HTML document). Another differentiating point of Process modules is that if you have a .css or .js file in the same directory as the .module, with the same name as the module, it will be automatically loaded. Lastly, if you edit any admin page, you'll see it lets you select what Process module to execute on that page. This logic can be applied beyond just the admin template if you want it to. It's a bit late here and I may be forgetting some things, so let me know if I'm not making sense or can provide any more info. But just wanted to reiterate that Process modules are very simple and there's not much to it.

I always just copy the files, dump the DB, and import with phpmyadmin on the new server, then update /site/config.php to point to the server's DB. But if there's some suspicion about an incompatibility with the server, I'll try to install a blank/default-profile copy of ProcessWire just to make sure it works (and I'll delete it afterwards). Sometimes I have to do a recursive update of the permissions of /site/assets to make it writable, but rarely. I need to get this actually built into the TinyMCE module so that people don't even have to think about it. +1 on the todo list.

Thanks and let us know what you find Neil. I think the $ undefined error, as well as the chrome dev tools not showing any errors sounds unusual, so if you get a chance try in another browser too. This sounds a lot more like client-side than server-side, so wondering what might be interfering with the JS. Your location does say Hong Kong… filters?

Thanks for testing Diogo and Soma! This was the last issue to resolve before making PW 2.2 final. Unless anything else turns up, I'll look to do a formal PW 2.2 announcement within the next 24-36 hours. I've posted the documentation for FieldtypeRepeater here: http://processwire.com/api/fieldtypes/repeaters/ Thanks, Ryan

@Diogo: Thanks for testing! Just to confirm, it's working how it should? It sounds to me like it is, but let me know if any of the behavior was unexpected. @Pete: I've updated the API for adding repeater items so that it is now simpler. Lets say that you've got a repeater field called 'buildings', and you want to add a new building. Here's how you can do it now: $building = $page->buildings->addNew(); $building->title = 'Sears Tower'; $building->height = 1400; $page->save(); That addNew() method can now be called on any repeater value. If there is a ready page waiting to be populated it returns that. If not, it will create a new page right there. It will be saved when you save your main $page. This hopefully makes the repeaters API a lot simpler.

It took me awhile to figure it out, but think I've finally fixed the issue that was occurring when pages with repeaters were cloned. I was wondering if anyone else that is using repeaters in a test environment would mind testing it out too? The fix is in the latest commit. To clone, you install the ProcessPageClone module (comes with PW core) and then click "copy" on any of the pages in the page tree that are using repeaters. I just want to confirm that the fix works for other people in addition to me. Thanks, Ryan

What are the components that people find useful in these frameworks? I know email and forms were mentioned previously. E-mail is something PHP does quite easily and well just with it's mail() function (though I understand some like to use alternate sending systems). When it comes to form systems, I don't feel like I've ever come across one that didn't leave me feeling like I wished I'd just built the form from scratch... though I'm working on something in that regard. But beyond email or forms, what are the components that people use in these frameworks? The only other component I commonly include in my ProcessWire installations is the Snoopy() class, for doing http requests. Beyond that, I've rarely come across a need to have other PHP components in my applications. Still, if there are some really common needs, perhaps we should look at expanding PW's performance as a framework and including more helpers/components for common needs. I'm just not sure what the needs are yet.

I think you'd make your own URL generation process. Lets say you've added a multi-language text field to your templates called 'url_name', you might do something like this, and call this URL() function rather than the url() function attached to every PW page: function URL(Page $page) { $language = wire('user')->language; if($language->isDefault()) return $page->url; $url = ''; foreach($page->parents as $p) { $url = '/' . $p->url_name . $url; } $url = '/' . $language->name . $url . $page->url_name . '/'; return $url; } I think that the slim solution is to use multiple trees. But I agree with the advantages of being able to specify page names in different languages, for the same page. I just don't currently know how to build that in without adding huge amounts of complexity to the system. It's something I will keep thinking about here in case any straightforward technical solutions become apparent.

Are you talking about example 3 from this page? There won't be a simple way to use different page names there since one page can't have multiple names. You could always add your own field to the page to hold it's name in other languages, and have your language-gateway template attempt to load them by that field. But I think that in the case you are describing, multi-tree would be preferable.

Hard to tell without seeing what error is occurring. Check your /site/assets/logs/errors.txt file and see what it says. If you can't find it there, try turning on the developer tools in Chrome: View > Developer > Developer Tools. Then in PW's PageList screen where it's hanging, hit reload. Look at the last request in the 'Network' tab of the Developer Tools. Click on it. Then click either the Preview or Response tab that appears on the right pane. You should see an error message. What does it say?

Pete, sorry I didn't catch your message before you'd figured this out yourself. But it looks to me like you got it right. As you found, repeater pages are kept unpublished+hidden until set otherwise. This is because repeaters may keep one or more 'ready' pages, that are ready to be populated in the admin. If there weren't any ready pages, then your repeater_field->first(); would return null rather than a Page. So if your ready pages were set at 0 for that field, then you'd want to start a new repeater page like this: $field = $fields->get('repeater_field_name'); $newRepeater = $field->type->getBlankRepeaterPage($page, $field); $newRepeater->status = Page::statusOn; // same as removing unpubished+hidden // ...populate any values to repeater... $newRepeater->save(); But you don't need to do this since you appear to have one or more ready pages already being created by the repeater, so your first() method works just fine. I still need to make a simpler API to the repeater field...

Looks good Diogo, thanks for posting. Only thing I wanted to mention is that it may be preferable to get the field value from the Inputfield rather than directly from $input->post. That's because the inputfield may perform some of it's own validation, providing you with a safer value. Though fieldtypes do some validation too, so your method isn't bad either. But getting values from the Inputfields themselves is preferable in many cases. Especially if you wan to display the form again with populated values, like if there's a missing required field or something. So your form processing could look something like this: if($input->post->submit_save) { $form->processInput($input->post); if(!$form->getErrors()) { $mypage->of(false); // turn off output formatting before setting values foreach($mypage->fields as $f) { $mypage->set($f->name, $form->get($f->name)->value); } } }

Great site Soma! Looks like a fantastic hotel and you really show it off nicely. I saw this first on my iPhone and really liked the experience there too.