teppo

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

@kongondo: I'm pretty sure we're talking about markdown extra code blocks here, not actual, executable code -- see http://michelf.ca/projects/php-markdown/extra/#fenced-code-blocks for an example. @John: are you sure your syntax is correct and you're not doing anything except simply echoing field value in your templates? Any chance you could post a sample of something that doesn't work for you here..? I'm testing this right now with above fenced code syntax and not having any issues. I'm running dev branch of ProcessWire though, in case that it makes any difference here.

That's essentially what Antti suggested on the linked thread, and as you can see from Ryan's reply it'll probably be added at some point. Like @DaveP pointed out above, I wouldn't worry too much about this.. though I do know of some sites that are steadily approaching that ext4 limit and wouldn't mind if this got tweaked soon(ish)

Personally I don't have an issue with current documentation, but I very rarely use it either -- cheatsheet is awesome and if something seems confusing I prefer to check it from source. This is why I'm wrong person to talk about the state of current documentation, but still: I don't think anyone here really has an issue with improving documentation *as long as it doesn't undermine it's current state of simplicity*, which seems to work very well for some folks out there. One issue is that in order to write better documentation people writing it need feedback, tips on what to improve and (optimally) even pointers to how that should happen. I'm seeing some concrete tips in what @Zahari wrote up there. Posts like that provide valuable information. One problem I'm seeing quite often these days are so-called "newbie questions" that have already been answered (usually multiple times) here on the forum.. or are *very clearly* answered within the docs. I'm not trying to discourage those who want to ask, I'm just worried since this obviously isn't optimal situation for anyone: the forum itself is great source of information, but people don't seem to find that information well enough. Have you seen @kongondos replies and how there are often bunch of links to similar threads in the end..? One problem might be that people don't do Google searches ("site:processwire.com categories" etc.) often enough. <voice type="semi-sarcastic">Perhaps what we really need is a how-to guide for finding stuff here.. and it needs to start with either "don't panic" or "forget forum search, Google it!" </voice> Sounds good and that's exactly what the wiki is for. It had an awesome start but now it's a bit quiet. If you'd fancy working for it, I'd suggest contacting Ryan (I think it needs registration, which doesn't seem to be open.)

@ryan: yes, it's an issue of regular mode only. I've been using inline mode since mentioning that here, so it hasn't been a problem for me anymore. It is still a bit odd, especially since there's still a config option for row number.. it just doesn't affect anything