teppo

This is intentional behavior. Personally I'd prefer to have this as a config setting somewhere, though, just to cover those (admittedly very rare) cases where huge pager makes sense.

RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] RewriteRule ^(.*)$ http://%1/$1 [R=301,L] Just for the record, you might want to consider the benefits of using www-subdomain before doing this, though.

Whether repeater or not, this sounds just like the solution we've been missing. I'm always worried about giving editors too much freedom, as I've seen how that often leads into bloated sites with very little structure (and eventually it's all so messed up that starting over from scratch is only solution), but by maintaining the control of what can be inserted and where this sounds like a very good compromise between giving the user enough freedom while still not letting her create a mess. Just for the record: I'm not too interested in small "campaign style" sites consisting of couple of pages, where any kind of mess is still controllable. Sites I'm worried about are those with hundreds, thousands, or even tens of thousands of pages. That's when things can very easily get out of control unless proper constraints are in place. PS. Reading that post made me spill coffee all over my laptop. Not sure if that's a sign of me being totally excited about this or simply a reminder to avoid any and all activities requiring hand-eye coordination before actually having that first cup of morning coffee.

@ryan: I'm afraid that's quite an overstatement, but thank you very much

Thanks, guys -- and thanks for the heads-up, looks like cache was preventing non-logged-in users from posting comments! Mysteriously some comments still got through, must've had perfect timing there (freshly expired cache)

Exactly what I was referring to above as instantiating MyAwesomeModule in the included file Taking another look at this situation: in case that you need any class variables of the original MyAwesomeModule instance, you'd probably be better off sending it ($this) to your included function as a param as explained in my previous reply.. and you might even want to send the $event object as another param, in case that you need to do something there that's related to the page you're saving: // in MyAwesomeModule: functionFromIncludedFile($this, $event); // and then in that function in your include file: function functionFromIncludedFile($awesome, $event) { $awesome->bla1(); $page = $event->arguments[0]; // etc. } This still sounds like something you could do without dependencies going all over the place (first class depending on second class depending on methods / variables of first class..) but I won't go there as I still don't know nearly enough of your needs

First of all, it sounds like you're doing something wrong, but I can't really say that for sure without seeing the whole context. Why do you need to split your class into multiple files? Typically classes are meant to encapsulate certain strongly interrelated features into one package, which is why this sounds like you're mixing different concepts together.. and I'm afraid the outcome of that won't be pretty Now, the easiest way would be to just drop the include or make it completely self-sufficient. Otherwise you'll probably either need to instantiate MyAwesomeModule inside that included file of yours and call bla1() from there or change bla1 into a static method and use it without actually instantiating MyAwesomeModule. If these don't fit your needs, you might be able to achieve this by sending instance of current class as a param for your included function -- functionFromIncludedFile($this). This way you could call it's public methods pretty much like you've described above.

Did couple of quick tests and there's no problem with this (just like @Soma pointed out above.) Sounds like it's something about your "more complex" thing that's broken.

@lowlines: you're probably already aware of this, but if you've got a sitemap planned out already and just want to quickly create matching pages, Batcher is very helpful for stuff like that. You should check it out if you haven't already.

Glad to hear that you got it working! It might make sense to add "overflow-x: auto" to your pre element in highlight.css; this isn't perfect as it brings out the scrollbar, but it's usually better than content overflowing somewhere it shouldn't go

@Ryan: thanks for detailed info! @John: I'll take a closer look at this once I get the chance, though what Ryan explained above should be pretty helpful already. Just got back from quick trip to Stockholm, still on mobile and a bit unsteady connection.. For the record, data-attributes don't work too well with purifier. I needed these for pbckcode to recognize the language next time I edit same code block (for some reason class wasn't enough) so I ended up modifying the plugin itself and changing all mentions of the data-lang simply to lang. Bit ugly perhaps, but that did the trick.

Sorry, on a mobile and can't remember exactly how pbckcode works on UI level but just to make sure: did you also enable it via field settings? Edit: in extra plugins add both sourcedialog and pbckcode to do this. If you view source of the page I linked above, you should notice that pre + code is not the only way to trigger highlight; you can toggle hljs for any element really. I'm using plain pre tags within article element myself.

Highlight.js doesn't really require <pre><code>..</code></pre>, that's just a suggestion in their documentation. See one of my posts here for an example: http://www.flamingruby.com/blog/php-for-template-designers/. All code blocks there are <pre> tags formatted with highlight.js (view page source to see hljs code in the header section.) You can define which blocks you want to highlight by using proper selector. Lang attributes etc. in the source are a result of the CKEditor plugin I mentioned above, you don't need to worry about those. They're not necessary and actually required a bit of customization to pbckcode plugin itself.

@John: SyntaxHighlight needs special class attributes ("brush: js" .etc), so make sure you've got those in place. Otherwise it won't highlight anything. If you're not interested in adding these, you might want to check highlight.js out. Doesn't require anything special from the markup, which can make things easier.

@John: it's possible that you'll have to add both pre and code to your field settings. When you edit that particular field, see Input > TinyMCE Advanced Configuration Options > valid_elements. If these tags are not included there, you'll have to add them first (simply append ,code,pre to existing content there.) When replying, you can attach an image by hitting "More Reply Options". This way you should get the full editor view and at the bottom there should be file upload options. Edit: taking another look at your screenshot, I don't think those fenced code blocks even should work. Currently you've probably got a paragraph containing "~~~~", another containing your code and then third paragraph containing again "~~~~" when you view the resulting markup, right? TinyMCE starts a new paragraph each time you hit enter, which might cause an issue here. You could try adding forced line breaks (shift+enter) after (and most likely before) your fences, to separate fences and code (and each line of code from eachother.) This could work better, but I'm not 100% sure about that either. Ultimately I don't think that Markdown extra will work nicely together with TinyMCE, so you'll probably be better off with simply using pre or code blocks created by the editor itself. I'm not sure why TinyMCE would strip <pre>, unless it's not include in the valid_elements setting, though. You could also try dropping TinyMCE and going with CKEditor. I find it more suitable for the kind of stuff I write, including code blocks within text (I use pbckcode plugin for actual code editing.)

@jmartsch: your PHP example seems like it should work properly, as far as I can tell. Have you actually tried this yet..?