teppo

It would be awesome if we could simply notify authors and they would update their content, but I'm also a bit skeptical if that would work, how many would react in given timeframe.. and how many modules we might end up losing in the process. Don't know if that's really worth the risk. For the paranoid types (like me) seeing what license a module is under is very important, especially if I'm planning to use it in work projects and not just for fun, but in all honesty most authors probably won't be going after users of their modules with legal claims anyway I don't really know what would be the best solution here and Ryan would probably be the right person to make that decision. In any case adding a way to define this info in the modules directory and sending an email like you mentioned would definitely be a good start. Using a license usually means including license text somewhere and/or mentioning in your source code what license it's under. GNU licenses (GPL, LGPL) are only ones I know to especially state that you should include full license text in every source code file you've got under that license. That's a bit over-the-top, to say the least, and most authors simply skip that part. For my own projects I've included LICENSE file within the repository and added PHPDoc @license tag (linking to text format license) to all PHP files -- that should at least make my intentions clear.

From legal perspective you can't really assume that, especially since we have already established that ProcessWire modules aren't automatically under same license as ProcessWire itself. There was a rather lengthy discussion about this here. Can't have it both ways, I'm afraid. Code that doesn't specify a license is simply protected by copyright law, meaning in essence that you can't use it legally without the authors consent. I'm no expert in (especially international) copyright law, so please don't take my word for it, though. Luckily more trustworthy sources, such as GitHub, have written tons of good articles about this

Small(ish) request related to modules directory: could we get a field for selecting license used by the module? At the moment it's often very unclear what's the licensing policy for an individual module. I'm hoping that this would -- in addition to making this information more obvious when browsing modules -- also give module authors a slight (and much needed, I'm afraid) nudge towards actually defining which license the module is distributed under. A simple text field would be enough for the time being, but a list of possible / most common licenses like GitHub has implemented would, of course, be even better.

Pages are the preferred way to do this and 30 pages is absolutely not a problem. You'll run into usability issues with select field itself much sooner than any kind of problem related to number of pages behind the scenes..

@pwired: that's one way to view it. From my point of view typography is an essential part of the design process and should be consistent across whole site, not something you (or the client) decides on a whim -- absolutely no offence intended, but from my experience that's what too much control eventually leads to. As a part of larger set of design decisions typography contributes towards the message that a particular site is designed to send to it's end-users. Classic example would be a "humorous" font used on otherwise very corporate-looking design. That's not just a sign of bad taste, it also sends a mixed message about the site and -- even more importantly -- the entity it represents, i.e. your client. Not only that, typography is also very important factor from usability point of view: Having the ability to change these things on the fly may feel good in that particular situation, but it contributes towards making the site messy and the experience end-users will have using it inconsistent and unpredictable, raising the bar of using the site among other issues. The client may or may not be expert when it comes to readability and other factors directly affected by typographic decisions. I'm personally not that interested whether a font looks good, but I am interested in whether it's readable. I do realise that this is something you can't always control. I just think that it's important to know what's being sacrificed when you're making choices like this. This is just one example of the kind of things you will sometimes have to explain to the client. If they still decide that this is important, then by all means go for it

I'm not particularly interested or knowledgeable in image optimisation myself (as long as I can still tell what's in the image and it doesn't consume too much disk space and/or cause unnecessary slowdowns all is good) but this sounds awesome! GD vs. Imagick is clearly something that's been bugging some folks and we'll likely be seeing even more topics about that in the future. I sincerely hope that you guys find the time to take this further

OT: for some reason a slight modification of this has stuck to my head; "expert is usually right, but the client always has the last word". As experts of our business it's our obligation to inform the client if something they're requesting doesn't make sense or if there's a better way to do it, but in the end it's the client who pays our bills and decides whether to trust our expertise

I've been reading about Hack this morning and I must admit that I'm getting quite excited, to say the least. Just wanted to share this with you folks, in case that someone else might find this interesting too. Long story short: Hack is a new language based on PHP, used and developed by Facebook. It's compatible with existing PHP code apart from certain features, such as variable variables, that they had to remove to keep things consistent. There's a bunch of new features that Hack introduces (such as asynchronous functions, lambda expressions and collections, just to name a few), but it's primary addition is (optional) static typing and real-time type checking via local server sniffing file changes -- something that should come in handy especially when working with larger and more complex codebases. For the record, I don't particularly have issues with PHP as it is, but it seems to me that Hack introduces exactly the kind of features that I've been missing without sacrificing anything I couldn't live without.. not to mention that this is another good reason to finally try HHVM, which is now able run both Hack and PHP

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..