teppo

Finally had time to take a closer look at that issue I mentioned earlier. So far it seems very similar to this one affecting Drupal Colorbox plugin, which in turn points to page at MSDN. This could also explain why using IE9 I'm "just" seeing a bunch of "undefined" errors regarding various objects in console, while earlier versions of IE seem to freeze entirely. This behavior was, after all, apparently altered in IE9 to address memory leak issues. @apeisa, have you heard of this issue earlier and if so, any chance you'd know how to fix it.. or if it even is what I think it is? Edit: solution mentioned in this Stack Overflow thread (clearing iframe src attribute before removing it) seems to do the trick, at least in IE9. Still needs more testing, but at the moment I'm not seeing errors mentioned earlier. This is what I've changed so far: --- AdminBar.js (revision xxx) +++ AdminBar.js (working copy) @@ -78,7 +78,7 @@ function slideUp(clean) { if (clean) { $adminbar.data('active', 'browse'); - $modal.find('iframe').remove(); + $modal.find('iframe').attr('src', '').remove(); setActive($browse); } $adminbar.data('active', 'browse');

This is doable with current tools already; you can either find/get specific page and render it with $page->render() at any given location (i.e. other existing page or even when a page isn't found by hooking to ProcessPageView::pageNotFound) or use URL segments to create fake page paths. To be honest this doesn't sound like something that would need to be implemented as a built-in feature. Edit: by the way, this thread is owning Google search results for keyword "svoesoderzhimoe"..

@SteveB: this looks very interesting. I had planned something similar (in the form of changesets, which would've been a bit bigger concept really), but your solution seems a *lot* simpler than what I had in mind. Would it be OK if I reviewed this, possibly made some small(ish) changes and implemented it as a part of the original module? Of course I'll add @author information to make it (as much as possible) obvious what part was written by whom.. Please note that I've just added LICENSE file, @license phpdoc tags etc. to clarify that this module is licensed under GPLv2. That has always been my intention, but it wasn't obvious earlier. This becomes especially important if code from other authors ends up in the module; that way their code included with the module would also be under GPLv2 from that point on. Thanks for reporting this, I'll have to take a closer look at the issue later.

Just for the record, it's good practice that if you edit your post later (especially with comments like "solved / figured it out"), make it very obvious to anyone reading it by adding something like "Edit: " in front of your addition. (I'm guessing that this is what happened here, i.e. that this issue is already solved and part of your message was added afterwards, but please correct me if I'm wrong.)

@joey102030: correct me if I'm wrong, but isn't PCI DSS important only if you're handling the payment directly through your service and/or storing credit card information or other related sensitive data about payments and/or your clients? Unless I'm mistaken, this isn't really much of an issue when you're using external service, such as PayPal, Paytrail (Finns mostly) etc. Handling just about any user information securely (over HTTPS, using proper certificate etc.) should be considered an absolute requirement, but obviously this isn't always the case, which is another reason why for most projects (where money or sensitive data are somehow involved) I'd strongly suggest using external service that pretty much has to do it "the right way."

@Joe: good to hear that you got it working @ryan: in order to be even remotely consistent, I'm posting here to say that I just suggested a small change in the Hanna Code thread regarding the default config.js of CKEditor shipped with this module.

@ryan: that definitely is strange, considering that with default config CKEditor encodes everything it possibly can; even single quotes get encoded per the entities_additional default value. Perhaps you've modified the config already? Anyway, my solution for this (and most CKEditor issues I've been dealing with) was simply adding config.entities = false to CKEditor's config.js. As you can see from CKEditor source, so-called base HTML entities (nbsp, gt, lt and amp) still get encoded, making this a very good default. As long as we're dealing with UTF-8 data, there shouldn't be any reason to encode everything. This also prevents issues such as search not working properly with Scandinavian characters ä/Ä, ö/Ö etc. Sure, searching from CKEditor fields is possible even with default config, but how many users would really try something like "Väinö" when they want to search for "Väinö"? Of course encoding search queries would be doable, but that would mean searching with both encoded and non-encoded versions.. As a matter of fact, I would like to suggest this as the default value for upcoming Inputfield CKEditor releases, unless someone knows of some terrible security issue this introduces. Edit: by the way, I do realize that the default config is much less of a problem for English speakers than us who have to deal with Scandinavian characters, umlauts etc. regularly. Still, it becomes a problem for just about everyone once they try to create multilanguage sites and/or use modules like Hanna Code, which is essentially why I believe that this would make sense as a default.

Hello there and welcome to the forum! A few quick answers and/or comments: 1. Awesome. Feel free to contribute any time you want 2. ProcessWire doesn't produce markup per se, so you can create whatever markup you wish and, for an example, use any layout / CSS framework you prefer. You simply create your templates as pure HTML (though within PHP files) and then ask ProcessWire to pull in content from current page to whatever location you want, with simple PHP syntax like <?php echo $page->body ?>. 3. CKEditor module is very configurable. Install it, see field settings and you'll find out just how far it can go. If you need any help, don't hesitate to ask. Personally I prefer to control stuff like font colors via style sheets so the site doesn't end up looking like something a drunken unicorn left behind, but I get that this might in some instances be necessary. 4. Sounds reasonable. No need to start from the deep end. 5. Most likely no. Again, you won't need to start with complex stuff, simply echoing out content takes you long way already. I wrote a blog post some time ago comparing PHP templating to Twig (and explaining the basics), so you might want to check that one out here if you're more familiar with other templating engines. 6. Some people prefer tutorials, others start with the documentation, personally I started learning with a real project (by the end of which I had pretty much grasped all the basic concepts of PW.) It's your choice really, but whatever route you take there's a lot of material available already. Again; ask and you shall receive (pointers for where to look, that is)

Peter, thanks for sharing this -- always interesting to hear how others are solving issues like migration from one system to another. I'll have to read this more carefully later, just had a chance to browse through and check out the code parts. Two quick comments on those, though: This might be just a question of preference, but it looks like you could've easily used Hanna Code for those snippets. Personally I've got a tendency to go with the "as little custom code as possible" route, and so I might've preferred that. You don't really need to redirect user to 404 page, especially not with a hard-coded path (though it's unlikely to change). You can get current 404 page with $config->http404PageID and use it's real ("dynamic") URL or you can simply throw a Wire404Exception(). Again, thanks for sharing this with us. Very much appreciated

@Julian: since PW is simply using MySQL NOW() function, I'm guessing that your database has different opinion about correct timezone than PW. Typically it would be using the server timezone, but that's not entirely certain. This Stack Overflow thread contains some tips that could prove useful here.

Just a quick heads-up: like you've already pointed out above yourself, you really shouldn't do this, as it seems to open a ton of new security issues. There are probably even better ways to do it, but why don't you at least create a new page (or Process module) and use PW API to handle the saving? It should be pretty straightforward, i.e. something like this: <?php if ($user->hasRole('admin')) { $target_page_id = (int) $input->get->page; if ($target_page_id) { $target_page = $pages->get($target_page_id); if ($target_page->id) { if ($user->hasPermission('page-edit', $target_page)) { $content = $input->post->content; $target_page->of(false); $target_page->body = $content; $target_page->save(); } else throw new WireException("Permission issue"); } else throw new WireException("Page not found"); } else throw new WireException("Missing page ID"); } else throw new WireException("Missing role"); Generally speaking, whenever you find yourself fetching (or, even worse, storing) data to/from native PW database tables, it's likely that you're doing something wrong (Exceptions above exist mostly to demonstrate couple of things you'll want to take care of if you do this at template level. Process modules have their own method of handling permissions, which makes that part less complex. Note that this was written in browser and I've no idea if that code works straight away, but I hope you'll get the point..)

@pwired: depends a lot on your needs -- whether you're just hosting the development environment etc. Self-hosting development environment is doable, but I wouldn't really consider hosting production environment for any other use case than in a small company working with couple of smaller clients myself. Once larger clients, SLAs, HA-requirements etc. enter the picture, simply managing the infrastructure is going to require full-time employee (with proper skills, not just a developer with rudimentary *NIX experience) working on it and being on call 24/7, which can get expensive. I've also seen clients require that the environment be set up in multiple geographical locations, be guarded from physical theft and natural disasters, be able to survive DDoS etc. -- not necessarily something you'll want to (or even be able to) handle yourself. Another important thing to mention is that when you're using cloud-based solution you'll typically pay for what you use, not all those extra resources you'll need to have with that self-hosted alternative just to survive short-term usage spikes etc. You also don't need to worry about periodically upgrading your machinery and won't necessarily even have to commit to a long-term contract (further decreasing involved risks.) All things considered I'd say it's pretty damn good deal, actually

I must say that I agree with both views here; what Martijn described is definitely a nuisance and I really wouldn't mind if Soma decided to change it, but it also feels that it's just wrong (and inconsistent) to have fields behave in different way when used in module settings context

I work on multiple devices, ranging from phones (rarely) and tablets (not so rarely) to desktop machines. Having everything properly set up no matter what device I start (and no matter whether I've ever even used it before) is cool. I'm also most productive when I don't have to spend time adapting to new environment every time I start different machine, so having a consistent experience would definitely be a big plus. Personally I've solved most of these by having everything set up server-side, making browser and SSH client (and, though that's apparently going to change pretty soon, Photoshop) only things I really need to start working and be productive. Nevertheless I can see why some people might not like that and would actually prefer some horrible mouse-driven graphical IDE and other similar productivity killers.. From company's point of view, on the other hand, this just makes sense; not only does it make new kind of collaboration possible (like Joss already pointed out) and (theoretically) even make moving people from one project to another a breeze, it can also decrease costs of each new employee. No more high-end Macs, pricey IDEs and self-hosted complicated environments when all you need is couple of cheap thin clients and web-based, monthly billed app. That, and the (sad) fact that when that environment is developed far enough your employees don't really even need to know what's happening behind the scenes (Git, whatsthat?) when everything just magically works. Lower requirements when hiring new people often equal lower salaries.. and each new guy takes shorter time to learn the ropes and start being productive. I could list a dozen or so other benefits, but I think this pretty much summarizes it

In addition to that, if you really just need to save one field, you can always use $page->save("my_field"). Logic (change tracking etc.) behind it is a bit different, but it's also usually faster. Not that it would, in most cases, really matter Edit: by the way, it looks like Ryan's example is about creating new pages with a custom frontend form? If you want to edit one field of current page, it's a bit easier than that; no need to create new page etc. as you can simply set value from $input->post->my_field to $page->my_field and call $page->save() (or $page->save("my_field")). Don't forget to use $sanitizer, though..

I don't have definitive answers either, but it sounds a lot like you're not doing something properly; what do you mean by removing install.php, are you trying to install PW "manually" without it by simply renaming site-default directory to site and adding DB config to site config? If that's the case, I'd double check that you're actually doing everything install.php does for you, i.e. importing site SQL, creating superuser account etc. Another thing to note is that MySQL password limitation you mentioned has been fixed in dev branch, so I'd strongly suggest that you try installing it instead of master branch. It's quite stable already (I've been using it for my own site for months without any serious issues) and contains many small fixes and some very nice additions too when compared to master. Edit: if this doesn't help, posting the DB error you're getting would be very helpful. Without that we can only guess what could be wrong

@Joe: I'm not entirely sure if there's something helpful there, but Aloha editor and integrating it into PW was discussed in the Adminbar thread some time ago and Ryan even provided some sample code that might be helpful. You might want to check that discussion out.