teppo

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

@Macrura: sorry for the slow reply, but.. no. This is loosely related to a discussion at GitHub, here: https://github.com/ryancramerdesign/ProcessWire/issues/566. I'd like to hear what Ryan has to say about CC, BCC and attachments before going and putting together custom solution for that. My opinion is that all of these should be implemented in the base class (WireMail) so that WireMail module authors (at the moment meaning mostly me and Horst) don't have to cook up case-by-case solutions. Even if the modules still required some customisation and couldn't use WireMail features out of the box, at least we'd have compatible implementations.

It's a good thing that ProcessWire has the flexibility of an Olympic gymnast. We can already extend it to so many different ways without having to somehow compromise the core package. Whether it's new site profiles, theming systems or whatever we can dream up, that's already doable. Doesn't mean that everyone has to love and use them, though. What I'm trying to say here is essentially that it's not away from you if someone builds a themable site profile. You don't have to use that, you are free to keep on doing what you're already doing. Relax. As an example of this from slightly different angle, I personally have a very strong dislike of so-called templating systems. From my point of view they complicate things unnecessarily and only result in worse quality. I'm still happy every time I hear that someone has built a cool templating system module for ProcessWire or a cool site using Twig / Smarty / whatever. That's good for them -- and what's good for them is usually good for the community. This is one comment here that really stuck with me, but not necessarily for the most obvious reason. I've seen many (nowadays) very competent developers emerging from the muddy waters of less flexible CMS'. I guess I mean that this works the other way around too; low barrier of entry brings in developers who might not be that experienced yet, but once they get the feel of it they can become very productive members of the community. Seen that happen here too. On the other hand, it's kind of sad seeing how some folks grow (professionally) in an environment that forces them to bad practices, and once they've reached a level at which they could do something really awesome, they keep trying to force that inflexible system to do something it was never intended to do, because it's the only thing they really know and jumping into another environment entirely is a scary thing to do.

This is great, Philipp -- thanks! I'm tempted to forward this to a few co-workers right away Two minor additions you might want to consider: a note about inserting images within RTE (mainly from alt tags point of view, but also that PW automagically resizes images, which in turn reduces unnecessary load) and Redirects module.

I'm going to agree with Nico here; a properly built theming system, separate from core package, would be a godsend. I'm assuming that nobody really means that, but I can't help noticing that every time a discussion about having more site profiles, easier installation for site profiles, some sort of theming etc. raises it's head, there's a sudden and mutual urge to kill it with fire. The way I see it ... Site profiles are not away from core development. Ryan doesn't have to spend his time working on these. Easy method of picking the profile you like during installation would be cool, but not necessary. Theming isn't evil per se. We don't need theming support in core, we can build it using modules (as Nico said) or simply using template level code. I've done both.. without losing my sanity. If someone feels that having easy-to-use site profiles and plug-in modules is away from hardcore developers and flexibility of the core itself, think again. These are not mutually exclusive things. Just my five cents. Take it with a grain of salt, please -- I'm in the middle of coding streak and just needed to vent my brain for a sec. Keep on keeping on.

@Nick: I'd like to point out that the approach you're taking is not what I'd advice on doing. It's very important to understand that ProcessWire is, first and foremost, a CMF. What this means is that it's very good at dealing with various content items (which it calls "pages"), describing the schema of those items, allowing you to manage them via API calls, define relations between them etc. Without going into too much detail about this, I'll just say that by using ProcessWire's own tools you are not just getting more benefit out of the system, but also more likely to build a solution that's manageable in the long run, easy to extend and update via built-in tools.. and, perhaps most importantly, as safe as possible (as long as you prefer API calls over SQL there's literally no way for SQL injection issues to creep into your code). What you are doing here sounds essentially like taking ProcessWire as a starting point but then coding an application that does effectively the same thing over and around it. This approach fits better one of the more bare-bones application frameworks (Zend Framework, Laravel etc.) It may seem like the obvious choice before you get to know ProcessWire's capacity and set of features (and there are valid use cases for it even then), but I hope you see why I don't think it's the best option in this case Anyway, since ultimately you should do what you see as the best option here: With ProcessWire you don't typically add columns to database tables or new tables to the database, so there's no UI for this (apart from PHPMyAdmin, of course, if you prefer something like that). You can communicate with the database using API variable $database, which is just a fancy way to use PDO style queries directly from your own code. You can see some examples of that in the source of my Version Control module. It's a bit old topic (there's probably newer material available too if you try searching the forum), but here's some discussion about custom login forms. Personally I tend to avoid custom login forms and rather allow users to login via native login page. This is connected to the fact that I don't like creating new custom Admin tools for them either and would much rather either let them use built-in tools or create a new Process module for them to use (method no. 3 in my earlier post). Hope this helps a bit.

Pretty much the same old arguments there: no front-end themes, end-user can't add new functionality via back-end and "it doesn't look like WordPress". Based on a couple of rather similar reviews (bad choice of words, but anyway) I'd say that it probably wouldn't hurt if we had more site profiles available.. and if they were more obviously visible at processwire.com. I feel that this is one area where we're a bit behind from what we should've / could've done, since people only just getting to know PW tend to miss these entirely. Just saying.

Each landing page is effectively it's own mini-site. Not sure what else to say here -- they'll be considered separate, small sites by Google and other crawlers. They themselves probably won't rank extremely high (Google likes quality content that is updated often), unless they're targeting a niche keyword. I'm not really sure what you mean by this. Care to elaborate? Yes. This depends on how your menu has been setup. You'll have to skip those pages one way or another -- make them hidden or exclude the template they use in the code that builds your menu. You should enter all hostnames you're going to use, i.e. your main domain, all the domains used by the landing pages etc.

This isn't exactly what I had in mind (thought you had those users already, just wanted to give them permission to edit a page), but there's an example of creating an user at the bottom of the $user page. If you just want to use Page Edit Per User and grant specific user access to a page via API, that looks more like this: // I'm assuming that you're already creating pages via API; not going into detail about that.. $p = new Page; $p->template = $templates->get("some-template"); $p->parent = $pages->get("/some-parent/"); $p->name = "some-page-name"; $p->save(); // give current current user access to edit previously created page $user->editable_pages->add($p); $user->save('editable_pages');

If you've already got a form that allows the user to create a page.. why not simply make the form add the user access to edit created page too? Unless that's possible, I'd suggest creating a new module based on Page Edit Per User; instead of current onMyBranch() method, simply check if given page was created by current user and based on that return true or false.