ryan

Wow, looks like we're about to go exponential on that graph there. The singularity is near!

The 404 page is a system page, so it's a special type of page that has a predefined purpose in the system. It's best to leave it where it is and work with it. What I would suggest is creating a new template and assigning that to the 404 existing page. That template should display a "page not found" message in multiple languages. But if you wanted to take it further, you could detect language was at the beginning of the URL (via PHP's $_SERVER['REQUEST_URI']) and output a language specific version, or pull in another language-specific 404 page and echo $otherPage->render(); Since there are multiple routes you could take here, from very simple to more complex, this may be something worth leaving to the individual installations to handle on their own according to their needs.

formmailer, try this: #CommentForm_text { width: 75%; }

No problem–this has been added to the issue queue at GitHub.

That preview looks awesome. I can't seem to get it to work here though (FF7). I'm getting a JS error "event is not defined" on this line in InputfieldCropImage.js: if( event.type === 'mouseover' ) {

Check your file permissions, I'm guessing that Apache can't read the new /wire/ directory. Also make sure that the entire /wire/ structure is there. The error that you are getting is a result of PW not being able to find or open this file: /wire/modules/Process/ProcessPageView.module

That's correct that the majority of the installation is all done by the installer. Here are the current install directions from the readme file (below). If anyone's found lack of clarity here, maybe it would make sense to repeat them in more places (it can't hurt anyway). INSTALLATION FROM ZIP 1. Unzip the ProcessWire installation file to the location where you want it installed on your web server. 2. Load the location that you unzipped (or uploaded) the files to in your web browser. This will initiate the ProcessWire installer. The installer will guide you through the rest of the installation. INSTALLATION FROM GIT 1. Git clone ProcessWire to the place where you want to install it. 2. Load the location where you installed ProcessWire into your browser. This will initiate the ProcessWire installer. The installer will guide you through the rest of the installation.

To save module config data, put the data you want to save in an array and then call the $modules API var with the saveModuleConfigData function. <?php $data = array( 'something' => 'Well hello there', 'something_else' => 1234, ); $module = 'ModuleClassName'; // can also be instance of module wire('modules')->saveModuleConfigData($module, $data); ProcessWire will automatically set the keys from your configData to the module when it loads, so you don't have to do anything else. As a result, your module could call upon a value like $this->something; and the value would be there. Or if you want, you can add a setConfigData(array $data) function to your module, and it will set the config data to that instead (when the module is loaded). Though I rarely do this. To retrieve a module's config data from another module or elsewhere in the API, you can also use $modules->getModuleConfigData('ModuleClassName'); Use it like this: <?php $data = wire('modules')->getModuleConfigData('ModuleClassName'); echo $data['something']; // displays 'Well hello there' The $data would be the same array that you set in the first example.

This line failed to load a user: $u = $users->get($uid); User ID 40 doesn't exist in the system because anytime PW returns a NullPage that means it didn't find what you were looking for. The best way to check if you got a NullPage is to see if the returned has an ID. So your last section of code should be something like this: if ($u->id && $u->hasRole($role)){ ...stuff } Btw, ID 40 is the default ID for the 'guest' user account, so it would be unusual if that really is the ID of the user and it didn't load.

Today I needed to install the latest Textile on an older site for a client, and figured I would go ahead and make a PW2 module out of it at the same time. Textile is the markdown language included with Textpattern CMS and apparently also used by Basecamp and Google+ to some extent. More information about Textile and syntax here: http://en.wikipedia....kup_language%29 Textile is very similar to Markdown (already included with PW), though now that I've spent some time with the syntax, I think I might like Textile a little more. To Install Download or clone from GitHub at: https://github.com/r...ormatterTextile Place files in /site/modules/TextformatterTextile/. Go to Modules in the admin, 'Check for new modules' and click install for Textile under the Textformatter section. You'll also see 'Textile Restricted' and that is a separate version of the module that may be used with untrusted input like user-supplied input or blog comments. The regular Textile should only be used with trusted input. To use Add this to any textarea (or text) field, and that field will interpret Textile codes and output XHTML markup on the front end of your site. Note that Textformatters appear on the 'Details' tab of the field editor when editing a text or textarea field. Use the regular 'Textile' unless the field in question may contain untrusted user input, in which case you should use 'Textile Restricted'. Please note Don't use this in combination with other text formatters like Markdown. Don't use with TinyMCE (there would be no point). This module may be used with any version of ProcessWire: 2.0, 2.1 or 2.2+.

Nice work Antti! This is really coming together nicely.

Selfthinker--I'm catching up here. I welcome the conversation and I think you are trying to listen, but also think you are on the defense first. Forgive me if I'm wrong, but you are saying things that are unusual for long time CMS users and I'm not sure you are understanding. I want to give you the benefit of the doubt but also want us to be respectful of our members here that are taking their time to politely reply (WillyC excluded). I understand you are here to defend your review. I can appreciate that and that is totally okay. I am happy anytime somebody wants to write about ProcessWire, and especially when they want to include it in their top choices. However, I think I'm at fault for correcting points from your review in the forum and putting you on the defense. Ultimately I am glad that you took the time to include ProcessWire in your review and thank you for doing so. If you are interested in developing a site in ProcessWire and gaining the experience of using it on a site, then I think you are in the right place. In such a case, it's great to pose questions to our team, and this conversation should move forward. But if you don't have an intention of learning and using ProcessWire, then I would suggest you put your time and energy towards the open source CMS project that does fit your needs. I believe that ProcessWire is a good solution for many, but not for all. However I also believe that open source is the right solution for all, so those of us participating in it need to focus our time and energy towards the systems that best meet our needs.

The profile page actually does use the user template, but it only lets the user edit the fields you designate. You can let them edit any fields you've added the user template. First add them to the user template. Then go to Modules > Process > User Profile, and check the boxes for the fields you want the user to be able to edit on the profile screen.

Your getThumb method could figure out the field, but not a very direct way. It would have to go back to the owning $page and see what fields it had, and match that up to the type you are looking for. I'm thinking something like this: <?php foreach($img->page->fields as $field) { if($field->type instanceof FieldtypeCropImage) { // $field may be the one you want // unless multiple FieldtypeCropImage fields on this page } } If you defined your crop settings with the module itself, then it might be simpler as it would already have the crop settings available to it.

Welcome to the forums blop! I don't yet have the skyscrapers profile setup for version 2.1, at least not in a distributable fashion. But I should have it soon.

Without some common field to tie them together, all you've got is structure and order. I don't think it's safe to grab the whole structure in one field operation because there won't be a consistent way to map the sorting. I think you have to go through it one page at a time, keep track of what level you are at, and use children() recursively. Perhaps not far off from a simple site-map script: http://processwire.com/sitemap.sh.txt But even in this case, the two trees would have to be identical in hierarchy, quantity of pages, and order, to map them properly. Maybe that's okay, but still something to consider.

I found something similar after googling around a bit, and someone suggested using upload_tmp_dir when there were open_base dir config problems on the server. it's already committed in the source if you want to grab the latest–please let me know if that resolves it? It sounds like they basically have a configuration problem there (or a PHP bug?) because PHP's sys_get_temp_dir() is returning a directory that it can't actually use.

Whe you call $modules->get('InputfieldCropImage') it is returning an Inputfield to you without any state or connection to a field in the system. So the only config values it would have would be those that are defined with the module itself (on Modules > Inputfield > InputfieldCropImage). Also note that it's better to set defaults in a __construct() rather than an init() because PW populates that module configuration after __construct() and before init(). So you could be overwriting the config values PW set if you were doing it in init(). I don't have the module's code in front of me here, but if I recall, that 'crop' value was set when editing the field under Setup > Fields? If so, you could just get it from the field. So if the field was called 'images', you could get it like this: $crops = wire('fields')->get('images')->crops; The reason your Inputfield may have had that crops value before is because it likely had the context of a field, like 'images'. But if you don't have that context, then you can just as easily grab it from the field directly. PW stores both the Fieldtype and Inputfield context with the PW field itself, so it doesn't necessarily matter much. But in general, it's better to define any values you would need in the API with the Fieldtype rather than the Inputfield. The reason is that the Inputfield is only applicable when editing in the admin. Whereas the Fieldtype is always applicable in the API. So in your case, I think it probably is better to store them with the Fieldtype, but I wouldn't bother to switch it unless it's easy to do.

Looking at the phpinfo link, it appears the open_basedir restriction is being used on this server. That prevents PHP from accessing files outside of the directory specified in that option. If your PHP's sys_get_temp_dir() function was returning a directory not included in the open_basedir, then that could feasibly cause the problem you are experiencing. Nico, I'm wondering if you can upload this test.php script to your server and see what it does: <?php $tmpName = tempnam(sys_get_temp_dir(), 'test.txt'); echo "<p>Attempting to write to: $tmpName</p>"; file_put_contents($tmpName, "It worked, no problem here."); echo "<p>" . file_get_contents($tmpName) . "</p>"; If it says "It worked, no problem here." then this isn't the issue. But if you don't get that, or if you get some error message, than that would mean there's a PHP config problem (and maybe something we can work around).

If the pages used the same URL names (minus the root), then it would be relatively easy to map them. But for multi language pages, I'm guessing you'd want language specific URL names. So I think that would leave you with having to map them by page reference. While you could loop both like that, I think it might be challenging. The sort order would not be predictable unless you forced some order. But your two branches would have to match up exactly in order to map them. It seems like a page reference back to the master tree, for each page, would be the simplest way to map them. That way you would not have to ensure each tree is identical. PageArrays are keyed by integers, and those integers only represent when the page was added to it. Meaning, they aren't useful for mapping. However, you can treat PageArrays like regular arrays and manually force them to use page IDs, but I'm not sure that would be useful in your case. Can you tell more about what you are trying to do? Maybe there are other approaches that would become clear with a broader look.

That's interesting to see that TinyMCE came out a little ahead there. As much time as it took to really integrate TinyMCE I'm not all that enthusiastic about doing it all over again unless replacing it with something substantially better. It actually is easy to provide these as Fieldtypes, but all the time goes into tweaking them, making them configurable, and especially providing the custom image/link insertion capabilities.

Great links Martin. As for books, I think that looks like it could be a good one. Though with only 4 reviews, it's hard to tell, but I can't say that I've ever come across a bad PHP book. I've never been able to really learn stuff online like I can with books. I must be old fashioned like that, but I need to sit down with a book, away from the computer, and read through it all before I can really start to absorb it. One of the nice things about PHP books is that PHP itself is pretty timeless in that it's a reliable constant over long periods of time when new technologies keep popping up and disappearing. As a result, I like putting time towards mastering things like PHP, regular expressions, unix, vim, git, because you know they'll still be your tools 5, 10 years from now. So it doesn't really matter if you are buying a PHP book from 2008. So long as it's a book about PHP5 (not PHP4) then all is good.

Nice update for localization! I don't know of a better way to get those local day names, but this would be one way to potentially improve the existing method. In this snippet, I'm just putting the localized day names directly into the $weekDayNames array, since that's where they go anyway. <?php $weekDayNames = array(); $time = strtotime("2011-11-14 00:00:00"); // a known Monday for($day = 1; $day <= 7; $day++) { $weekDayNames[$day] = strftime('%a', $time); $time += 86400; // +1 day }

Yes, templates will have labels like fields do. Actually this is something I can go ahead and add before 2.2, and the 2.2 modules will just make them multi language.

If you want to set me up with SSH or FTP access as a PW login, I'll be happy to take a closer look at it this week and hopefully track down why it's not working in this situation. Just drop me a PM or email my name 'ryan' at this domain, and we'll get it figured out. Also, if you have the time, it might be worth trying to install a blank/fresh copy of the latest PW in another directory and just see if you can upload files there (using the default profile it comes with). That would at least point to whether we should be looking at the server side config or something specific to the installation you are working with now.