teppo

This isn't currently supported and needs a new option for CKEditor module to work. CKEditor itself has support for custom config file. So far I can't see why this wouldn't be doable, either. This is how config load order is explained in the CKEditor docs: An editor instance is created. At this point all its default configuration options are set. If the customConfig setting has been set "in-page", that file is loaded, otherwise the default config.js file is loaded. All settings in the custom configuration file override current instance settings. If the settings loaded in step 2 also define a new customConfig value, another custom configuration file is loaded and its settings override current instance settings. This happens recursively for all files until no customConfig is defined. Finally the settings defined "in-page" override current instance settings (except customConfig, which has been used in step 1). I'll also have to agree that this is very important option to have. Config.js (in one form or another) is meant to be customised.

In our case the problem wasn't repeater in repeater, so it looks to me like the underlying issue remains unsolved; I'll have to continue debugging that one at some point, but for now it's great to hear that your case was resolved. Hopefully I'll be able to grab something useful from what you've posted here, so thanks for that!

Just for the record (I can see that other arguments have already kicked in), I'd like to point out that this would also require ProcessWire (and thus your Apache user) to be able to create and modify files within /site/templates/. This, in my humble opinion, is not a good idea; even with proper safeguards in place, web-writable executable files open all sorts of possibilities for abuse. You don't want to go that route unless you absolutely need to -- and I can't imagine any situation where I'd actually want to do that.

Just a quick update: I've been experiencing this issue on a couple of sites too. Don't have a definite solution, but it's great (well, in a way..) to know that it's not just me. So far all I know is that this is quite likely connected to change tracking and triggered only by very specific conditions -- having a repeater with Page type field in it and selecting root page more than once triggered it in one specific case, but only if there was more than one repeater on that page (etc.) Kind of hard to post an issue for it when it happens on one site but identical setup built from scratch doesn't suffer from it Note: I can confirm that PW version doesn't matter here.. at least around 2.4.5 the issue still persisted. I'm not aware of any updates that could've fixed this since then.

@kongondo: all I really did was alter pbckcode's JS file to change all 'data-lang' attributes to 'lang' and add following to exra allowed content: pre[class,lang](*); Have you made the changes to the plugin already and what sort of markup does it generate? Could you paste an example of a code block, preferably both states, i.e. what it looks before and after saving the page? As far as I can see, the problem could be a) necessary attributes getting stripped off during page save, b) them not being there in the first place or c) some change still missing from the plugin. Note: I haven't tested this in a while, so something could've changed since then.

@woop, it means roughly that instead of modifying files within /wire/modules/Fieldtype/FieldtypeComments/ directly, you'd copy entire FieldtypeComments directory to /site/modules/FieldtypeCommentsExtended/, change classnames etc. there to match that new name and then modify the code per your needs. Modifying code within /site/* is always safer and more future-proof than touching any code within /wire/*.

@pideluxe: agreed. That (basic theme groundwork) is exactly what I've been trying to suggest all along.. and exactly what Nico is doing with WireThemes project, so we're definitely on the same page here. I don't see having (more) 3rd party site profiles and/or themes (whatever you call them and however you put them together) as something that would seriously harm ProcessWire as a project, but that's just me Also, anyone repeating the "themes shouldn't be in core" mantra, take a closer look at this discussion: unless my memory is failing me, no-one has suggested such a thing. We're discussing third party themes here. Please don't get dragged into pointless argument over whether customisable, interchangeable themes should be in core -- they shouldn't, period.

@zwergo: admittedly I've no experience with StartSSL, apart from someone suggesting that to me a while ago (can't remember the context, though). At that time I checked their reviews (very good) but was put off by this: http://danconnor.com/post/50f65364a0fd5fd1f7000001/avoid_startcom_startssl_like_the_plague_. I'm pretty sure that there was something else too, but it might've been just the fact that they're offering free service, which made me wonder how trustworthy they could be (and how long would browser vendors etc. continue to trust them). Nevertheless, might just give them a try one of these days Something like GetSSL would be another option. I guess I could somehow scrape together the $9.95 their standard SSL certificate costs..

Actually.. it does. If their certs are not trusted by OS and browser vendors by default, they're pretty much useless for anything but testing purposes On a related note, this is IMHO a good (and very bold) move from Google -- one that I honestly didn't expect them to make, but am happy about nevertheless. Having a secure connection between you and the site you're trying to reach is definitely a plus and should affect the way (and the sites) people browse. That being said, it's going to cause some extra work for a lot of companies and people.. including me

@woop: I'd assume that Ryan was looking for best possible performance when building the comments system. Comments being it's own fieldtype with hardcoded schema increases it's performance and makes it possible to fine-tune everything especially for this use case. Main difference from pages is that those are usually something you create yourself and it's quite rare for sites to go beyond thousands of pages (though sites with hundreds of thousands of pages (or more) definitely exist). Comments, on the other hand, are something that visitors (guest users) can create without your consent, which means that there can be a lot of those.. that, and the fact that they're almost always identical between different sites, making "hardcoded schema" possible in the first place. If you require custom fields to Comments, you've got two choices at the moment: create your own Comments field based on what's included with ProcessWire (call it CommentsExtended or whatever you prefer) or hack the built-in module. I'd suggest creating your own field (option 1), mainly because hacking built-in components is never a good idea in the long term (updates get tricky etc.)

This looks awesome. Been playing with the demo for a while and, though I clearly don't yet understand much of what it's capable of, so far I'm very impressed. Seems like a very good example of building (relatively) large-scale application on top of ProcessWire You were wondering if this would make sense as a module. What I've seen so far makes me think that it probably wouldn't make that much sense. You could move individual features, functions etc. to modules in order to separate some of the business logic and perhaps even parts of markup generation from actual views (template files), but your current structure seems to fit this project pretty well too, so it's entirely up to you. Of course this sort of separation could be achieved simply by moving functions to include files, so a module isn't needed for that either. One quirk in the demo map is that whatever I type in the search field (left toolbar), "Fehler: Zeitüberschreitung der Anfrage in functions.js" is displayed. Perhaps something isn't working quite right there? Sorry, "a bit" off-topic, but this depends on which meaning of "steep learning curve" is used. I'll never be able to wrap my head around steep learning curve meaning that something is difficult to learn -- that's just plain wrong. Learning vs. time make so much more sense

Marek747, All languages have their ups and downs. "Language X is better than language Y" is just about as far from valid argument as you can get. For an example, if speed is your first goal and popularity second, it would make most sense to forget node.js, RoR, and any given framework for that matter (they always add some extra overhead) and go with plain C instead (although that's just about as "old-school" as you can get). C is widely acknowledged as one of the most popular programming languages (TIOBE, IEEE Spectrum, etc.) and it's definitely the go-to language if you want superior speed. That being said, web applications built on top of C are (to my best knowledge) very rare, and some developers would argue that it's not exactly an easy language to master. Just for comparison, something like Ruby (and Ruby on Rails, which is a framework you mentioned) is designed from a very different point of view: it was originally known to be very "hip", very comfortable to work with.. and extremely slow. (I'm assuming they've improved those figures since then – that was quite a while ago – but Ruby is still hardly your best choice if you need top notch performance.) If you want a language that's comfortable to work with, good for web application development (I'm assuming that's why you're here), and widely supported, go with PHP or Python. PHP is more widely used, which makes it a good choice. It's also ugly, inconsistent, etc. but a lot of developers have learned to live with those flaws because it's good at what really matters: getting shit done. Note: I'm not saying that JavaScript and/or node.js is a bad choice, but they're not quite as popular or well-established yet, and the future of the web is bloody hard to predict. It's definitely good to have knowledge of them, but in my opinion they're not quite there yet. Perhaps one day they'll power all the popular apps around, or perhaps they're a fading trend, nobody really knows.

Is ProcessWire A Viable WordPress Alternative? Apparently we've being noticed by the WordPress community.. not entirely sure if that's good or bad thing

@valan: I very much enjoyed reading your comments and many of them are familiar, in one form or another. Thank you for your input! One thing I do not fully agree, though, is the notion of "adding stuff to core". I get that the core has to evolve, but that doesn't necessarily mean it has to grow -- and in this single post, you're (in a way) suggesting three new additions: payment tools, some sort of MVC setup and Bootstrap (well, this is not so much an addition as it would be replacement for jQuery UI used right now). My opinion is that the core package has to remain as small and lean as possible. Any single addition to it has to be something that very high percentage of PW sites require -- and even then, if it can be sensibly built as a separate module/feature, in many cases I'd go with that. One of ProcessWire's key strengths is that it's modular and very flexible. We don't need features like payment modules, Form Builder, MVC template structure, site profiles (themeable or not), just to name a few, in the core, as those can all be built separately and plugged in when needed. This reduces the bloat that some other systems suffer from. Just my five cents.

@marcus: good point. Just wanted to use that as an example of a somewhat divisive feature that can be (and, in fact, has already been) added on top of core package without compromising the integrity of the core itself at all

Field 'editable_pages' is added by Page Edit Per User, if that's what you're referring to. Otherwise this is just standard API usage

On other news, I've just updated Swift Mailer bundled with the module from 5.0.3 to 5.2.1. This version includes a security fix, so anyone using this module should update. Note that the vulnerability doesn't affect this module; it's related to Reply-To, and this module doesn't, at the moment, use that in any way, but in case that someone is using the Swift Mailer library directly from this module's directory, that could still be a problem. Other updates added just today include minor fixes and vastly improved tools for testing mailing capabilities (including a tool for sending test messages directly from module's configuration screen).