teppo

Joss: I think I was being a bit too vague there Did you mean that it would actually be in default site profile's modules directory or still bundled with core modules, only not "permanent", or something else? I'm not sure if this would really be beneficial compared to current situation -- seems to me that the biggest issue with having TinyMCE and/or CKEditor built-in is that they're actually pretty damn big (TinyMCE 4.3M, CKEditor whopping 14M).

Peter: just to make sure, was that script block before InputfieldImage.js but after jQuery.js? Just checking since you mentioned that you moved it before "other" files.. Any chance that you could put this somewhere we can see it in action? That would be very helpful.

I seem to vaguely remember someone saying something about decoupling TinyMCE from core at some point. (Emphasis on "vaguely"..) Personally I wouldn't mind TinyMCE not being included with core, especially since I haven't really used it since CKEditor module came out, but I'm wondering if not having "built-in" RTE in ProcessWire might give bad impression to some folks just getting used to PW -- even if it's available as a module? I'm probably just overthinking this, though.

Peter: most likely issue is that "inputfieldFileLink" trick is done at InputfieldImage.js, so it happens before you add the classes and thus won't find anything. Move the custom script block (one containing .addClass()) before InputfieldImage.js and this should work better. Also, I'm guessing that you viewed source via browsers "View page source" tool? If so, that won't take any JS modifications into account -- make sure you use native dev tools or something like Firebug when debugging JavaScript issues.

Slight variation to what Martijn suggested above, you may want to make sure that only local images are affected: $('a[href*="/assets/files/"]:has(img)').addClass('InputfieldFileLink');

@SteveB and @ryan: good point about deleted pages, this is now taken care of. No idea why I didn't think of this earlier.

Not hard, just inconvenient. CKEditor in inline mode is comfortable enough to finally make writing with RTE in browser comparable to writing in text editor. Having one go-to tool instead of two feels slightly better. This is very much a question of preference, so there won't be any "correct answers" here -- some users prefer to write at Admin and others will probably always write with Word, Notepad, Notepad++ etc. AdminHotKeys is only partial answer to saving issues mentioned here, unless I'm missing something: it still requires reloading page, which (especially when working with crappy connections) can a) take ages and b) result in timeout and lost data if you're not careful. Isn't that exactly why we're discussing background save methods here? One more thing to note is that any autosave / background save feature will also need to handle exceptions (such as being momentarily disconnected) properly, otherwise they could even make things worse; user must know what's happening, when last successful save occurred, whether there are connection issues etc. Basic stuff, but very important nevertheless.

About a week ago I wrote a blog post while on train and some odd hiccup -- not sure if it was connection issue or just something I did wrong as I was using a tablet, which is far from perfect tool for this job -- but the whole post simply disappeared. Needless to say, I wasn't very happy. Sure, I should've saved more often, so it was really my mistake, but that was still an example of a situation where autosave would've saved the day (quite literally.) My needs are quite simple so I'm currently thinking of writing a very simple module for that purpose alone, but it's good to see that others are toying with similar ideas here. My issues are pretty far from a full-featured "save as draft" solution, but still

This is pretty much how I'd solve this, still no need for any core changes or additions Create new template called "symlink", add page type field "symlink" with value limited to single Page (use PageListSelect as input field type) and then in template file do something like this: <?php if ($page->symlink instanceof Page && $page->symlink !== $page) echo $page->symlink->render(); else throw new Wire404Exception(); Now you can add as many symlinks you wish and easily choose which page each is tied to. Don't forget to add canonical tags to let robots know which version of this page is the "original" one, though, or you'll have serious SEO issues.

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