teppo

Macrura is right -- mod_rewrite is essential for ProcessWire to function properly. Short answer is "it's not doable". Regarding your actual issue here, there are multiple notes about various possible 500 errors in ProcessWire's .htaccess file. If you're getting these errors, take a close look at that file and see if any of those tips can help you. If not, try posting more details here and we'll do our best to help you with this. Longer answer is that even if you could tweak ProcessWire to function without mod_rewrite, it would come with two huge drawbacks (that I can think of right now): your URLs would be like example.com/?it=/about/site/ instead of example.com/about/site/ you'd be compromising a lot of security features, such as protected directories and files Possibly even bigger issue would be that ProcessWire really isn't intended to work like that. Internal links, URLs and things like that are very likely to break here and there. In a nutshell: trust me, this is not a good idea.

Thanks for the heads-up, it always takes a while and I tend to forget that. Should be OK by now, I hope

There are multiple ways to handle XML in PHP, but for simplest tasks (reading) I prefer SimpleXML. After that it's all about iterating posts in XML and creating matching pages for them via API. Hope this helps a bit. PS. I did notice that you posted this on jobs board, but still wanted to point out that the XML part is really nothing to be worried about. If you're familiar with handling ProcessWire content via API, this should be a piece of cake, unless post data from WP is very complex

I've also been exporting "everything", though (like you said) the copy method obviously can't literally export everything.. These are the errors I get in the same situation, with repeater field added. Ready items for this repeater is set to 3 and you can view the final JSON output here. Notice: Trying to get property of non-object in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1403 Warning: Invalid argument supplied for foreach() in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1403 Notice: Trying to get property of non-object in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1038 Warning: Invalid argument supplied for foreach() in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1038 Warning: Invalid argument supplied for foreach() in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1026 Notice: Trying to get property of non-object in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1403 Warning: Invalid argument supplied for foreach() in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1403 Notice: Trying to get property of non-object in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1403 Warning: Invalid argument supplied for foreach() in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1403 Notice: Trying to get property of non-object in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1403 Warning: Invalid argument supplied for foreach() in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1403 Testing your zip file didn't go exactly as planned, though that was probably user error; didn't select "replace", tried to "append" with parent set to "home" and as a result I got "Integrity constraint violation: 1062 Duplicate entry 'about-1' for key 'name_parent_id'". Slightly weird thing here is that when trying this again with "replace", I got the same error, though this might be because something was broken earlier. Might have to setup another test site to see what's actually going on here -- if this works for you, there's most likely something wrong with my test site. One specific thing I'm not really comfortable with, though I'm not entirely sure if that's possible to avoid either, is that even though the import fails things like fields and templates are still added and/or kept. This could potentially leave the site in a kind of a strange state, with some old content and some new. It'd be cool if failed import "cleaned up the mess", so to speak Another thing that probably should be handled somehow are possible permission errors: Warning: copy(/site/templates///basic-page.php): failed to open stream: Permission denied in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 449 Warning: copy(/site/templates///gallery.php): failed to open stream: Permission denied in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 449 The reason for these is obvious and (again) I should've known better, but then again, the module could also check for necessary permissions beforehand -- or perhaps just interrupt the import the moment this happens and notify user to make sure that permissions need to be tweaked? .. and by the way, those template paths with three forward slashes look a bit strange, but that's far from fatal PS. I actually enjoy testing this module and see a lot of potential in it. As a matter of fact it's already proven it's worth in some of our projects, saving me quite literally hours of work, on more than one occasion. If it sounds like I'm only seeing bad things here, that couldn't be further from the truth

As a quick hack, if you replace this row: $error_message = "<h2 class='error'>Please check that you have completed all fields.</h2>"; With this: $error_message = "<h2 class='error'>Please check that you have completed all fields: $key</h2>"; .. you can debug what field exactly is not being filled. You might also want to remove the "break" right before that and append each new error to the message instead (change "=" to ".="). Edit: apparently you managed to get this working already, which is great. $sanitizer->text() clearing field(s) sounds strange, though, so you might want to take a closer look at why that was happening. Then again, whether that really matters depends a lot on how you're going to use this data.

Sorry for that. The problems seems to be quite different: in original code there was submit element with name "submit" and value "submit". You seem to have replaced that with button with right name but no value. Try adding value="submit" to your button and see if that helps.

@joe_ma: email not getting sent and the fact that you're not getting success message both indicate that in your environment PHP's mail() doesn't work. The reason for that can only be guessed, but to make sure I'd create a simple mail() call somewhere and see if you can actually send anything anywhere. If it turns out that mail() simply isn't working for you at all, first you'll want to check if your web host has any tips for this situation. This depends, of course, entirely on what kind of hosting setup you've got. It would also make sense to take a look at your error logs (/site/assets/logs/errors.txt), Apache error logs if you've got access to those and try this with debug mode turned on in your /site/config.php. See if there's anything strange happening when you're trying to send this email. Note that you should only set debug mode on if this is not a live site, you really don't want that to be turned on in production environment! (In case that you've got an SMTP server you can use for sending email, you could also try installing Wire Mail SMTP or Swift Mailer, but note that for either of these to work you'll need to use current dev branch of ProcessWire, which isn't necessarily a good idea for live site either!) About your second question: you can do that (append them to $success_message) or simply output them right after / before success message. Doesn't really matter, other than if you're trying to use values user submitted, you'll want to do that after the "$form = array( ..." line and use them from that array, so that they're sanitized: // set and sanitize our form field values $form = array( 'datum' => $sanitizer->text($input->post->datum), 'ankunftszeit' => $sanitizer->text($input->post->ankunftszeit), 'anzahl_plaetze' => $sanitizer->text($input->post->anzahl_plaetze), 'name' => $sanitizer->text($input->post->name), 'adresse' => $sanitizer->text($input->post->adresse), 'plz' => $sanitizer->text($input->post->plz), 'ort' => $sanitizer->text($input->post->ort), 'email' => $sanitizer->email($input->post->email), 'tel' => $sanitizer->text($input->post->tel), 'extras' => $sanitizer->textarea($input->post->extras), ); // append values to success message if ($form['datum']) $success_message .= "<br />Datum: " . $form['datum']; // etc.

@adrian, I've been testing this a bit and getting this after export: Notice: Trying to get property of non-object in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1038 Warning: Invalid argument supplied for foreach() in /site/modules/ProcessPageTreeMigrator/ProcessPageTreeMigrator.module on line 1038 Not sure if this affects the import process, though. At least pages get imported properly, but there is something a bit strange there too; see attached screenshot. "Following template files" seems to suggest that something was (supposed to be) migrated there too, but now it looks like somethings missing below that headline? Earlier this template had repeater field on it and I was seeing quite a bit more errors, so I removed the repeater field in case that was causing it somehow. Errors did actually go away, but only partly -- as you can see, some still remain. I'm running 2.4 master branch on a local MAMP installation with PHP 5.5.10. You can see exported data here.

@Lance: weird thing here is that nothing should've changed regarding passwords and hashes between 2.3 and 2.4. These parts of the code are exactly identical as far as I can tell. I'd try installing a fresh 2.4 on this server you're using. If it works properly, then the problem most definitely has something to do with stored users and the password reset trick just didn't (for some reason I can't quite comprehend) work. Another thing you could try would be creating entirely new user via API, so that it's definitely specific to this particular server.

None that I know of, but you can always do this: $fs = array("body", "title", "summary"); foreach ($fs as $f) $page->save($f); According to Page.php, for single field save you'll want to hook into Pages::saveField(). Isn't this exactly the same question that Wanze answered quite a while ago, or am I missing something? If you still need those wildcards, then it could, of course, get more complicated

Any chance that those links point to localhost? If this is a PW 2.4 site, make sure that you've got your sites current domain in /site/config.php httpHosts array (or that this array is empty, i.e. there's no "localhost" there).

A bit off-topic, but during an advertising course I took a couple of years ago our lecturer (old-school advertising guy who looked a lot like Joss in that profile pic.. coincidence?) told us that in advertising one never, ever uses particularly word "no", but also any other sort of negative approach. He was so strict about that one point that it kind of stuck to me and is, honestly speaking, pretty much the only thing I remember from that course at all..

Good clarifications from both of you This is getting a bit out of hand, but one more addition: in current code image isn't actually resized -- it's just forced to specific dimensions with HTML attributes. This could be intentional, but I'm wondering if this might make even more sense here: ... echo "<img src='{$p->images->first->size($resized_imageWidth, $resized_imageHeight)->url}' width='{$resized_imageWidth}' height='{$resized_imageHeight}'>" . "<a href='{$p->url}'>{$p->title}</a><br />"; ... This way end-user doesn't have to download excessively large images, if what you really want here is a thumb. It should also be noted that simply defining width and height with HTML attributes forces image to those exact dimensions without considering actual aspect ratio, which can easily result in distorted images. (More about various options that size() accepts here.)

Another clarification. (I seem to need these a lot these days.) As is (probably) made quite obvious by the SQL statements above, get() with a Page ID doesn't care about the status of the page at all. It returns hidden and unpublished pages too, making it somewhat equal to find() with "include=all". This is important to keep in mind in case that those pages you're "getting" could've been unpublished in the meantime; if that's possible, you really should add another check for $p->viewable() before displaying content. With this addition, nfil's final code could look like this: $resized_imageWidth = 120; $resized_imageHeight = 0; $session->history = is_array($session->history) ? array_slice(array_merge(array($page->id), $session->history), 0, 4) : array($page->id); foreach ($session->history as $page_id) { $p = $pages->get($page_id); if (!$p->viewable() || $p->template != "basic-page") continue; echo "<img src='{$p->images->first->url}' width='{$resized_imageWidth}' height='{$resized_imageHeight}'>" . "<a href='{$p->url}'>{$p->title}</a><br />"; }

Very good clarification. My explanation earlier was way too vague What I meant was that you can't find from a single page, i.e. use find like a filter for one page. You can find from children of given page, though: $pages->get(123)->find("template=basic-page") would return children of page 123 with template "basic-page" recursively, while $pages->get(123)->children("template=basic-page") would only return matching direct children. That's another way to do it. With find() you could also do something like this to, perhaps, simplify it a bit: $p = $pages->find("id=$page_id, template=basic-page")->first(); if (!$p) continue; echo .... Quick look at the SQL generated by get() vs. find(): SELECT id, templates_id FROM pages WHERE id=1001 SELECT pages.id,pages.parent_id,pages.templates_id FROM `pages` WHERE (pages.id=1001) AND (pages.templates_id=29) AND (pages.status<1024) GROUP BY pages.id /* Selector id=1001, template=basic-page, status<1024 */ I would assume first one (get) to be slightly faster, but this is micro-optimisation at it's best and doesn't usually matter at all in real world use. I prefer get() for getting single pages as it's the straightforward way

We've used Balsamiq for couple of years now and generally speaking I'm very happy with it as long as static wireframes go. Compared to other tools we used before (FlairBuilder and Photoshop mainly) it's been a huge improvement: type a few characters to find correct element (there's a menu for mouse addicts too), throw it to your canvas and drag to arrange while Balsamiq takes care of alignments etc. It has saved me countless hours of boring, repetitive work. One noteworthy downside with some other mockup tools was that they made things look too clean. Clients took one look and started commenting on colors, backgrounds, content etc. Lesson learned; mockups *should* look scruffy. This is probably pretty standard feature nowadays, though. Lately I've been transitioning to HTML wireframes, mostly for the reasons Reno mentioned already. Static mockups fail badly when it comes to visualizing how responsive site behaves on different situations.. and with PW I can actually make them fully functional while I'm at it, giving the client even better understanding about how the site is going to behave once finished

I'm glad I could help.. and this actually looks quite interesting, might have use for similar snippet somewhere

@nfil: $pages->get($page_id) returns one page and you can't "find" from one page Try adding new row after $p = $pages->get($pages_id) with something like this: if ($p->template != "basic-page") continue;

You might want to try what Ryan suggests here: http://processwire.com/talk/topic/1142-lots-of-sessions/?p=30237. Session garbage cleaning isn't currently working on certain systems with default config (more about that here). Garbage cleaning for sessions is always random and it's possible that it just hasn't happened for a while. Hard to say without knowing a bit more about your environment, how often new sessions are created etc. Anyway, above solution shouldn't cause any harm either, so I'd try if it helps.

Makes sense I usually do that with Chrome dev tools. It's not that pretty, but handles the job of collapsing, displaying data types and lengths etc. quite well.

Still somewhat ugly, but I'd probably go with something like this: $session->history = is_array($session->history) ? array_slice(array_merge(array($page->id), $session->history), 0, 4) : array($page->id); After that you can output stored data like this: foreach ($session->history as $page_id) { $p = $pages->get($page_id); echo "<a href='{$p->url}'>{$p->title}</a><br />"; }

.. and then there's var_dump(json_decode($json)). Seriously speaking, though, the quality of these tools is amazing. I'm having hard time imagining where I would use any of those, but they're all totally cool nevertheless