teppo

lisandi: would you mind opening a new thread somewhere, probably in the modules area, about this particular website builder tool you've mentioned a few times.. and/or any other specific ideas you've got? It seems that you've got ideas about specific tools you'd like to see integrated (or built) with ProcessWire, and by no means do we want to stand in your way, but I'm afraid that current thread is simply way too broad and way too long-winded to result in any real, solid, or useful outcome. As someone who should know a little bit about how this community works, I'd suggest that you try to keep those threads to the point; don't wander into philosophical stuff, just explain what you're planning to do and what you're expecting (hoping) from others. It looks like you've got a very interesting project (or couple of them, perhaps) in your mind, and you'll probably find a few like-minded folks around here if you just focus on one thing at a time By the way, earlier when I said that I can't showcase our non-public client projects, I really meant that. Our clients trust us to keep their private matters private, and we would never do anything that has even the slightest chance of compromising that trust. In fact, generally speaking we always ask for a permission before showcasing any client work, public or not. I hope you understand this, but even if you don't, that's how it goes. Just wanted to make this clear

Sounds like this would benefit from separate "not" / "negate" checkbox, or something like that. Just saying..

Marvin, this looks great -- the feature set has most of the things I can think of right now, and, in fact, this looks like something we could use pretty much out of the box. Many of our sites these days are using the UserGroups module, so I'd probably be looking into adding a few fine-tuning settings to make these modules work together nicely, though What's your take on cleaning up users/sessions, i.e. does this module check if user account is still valid and active (and, preferably, if groups have changed) in the AD? That's something we've found pretty important in "more serious" use cases. Also: do we get to play with the source, is this a free or commercial package.. what's your plan here?

Iisandi, that's a pretty good summary, and again, you've got some very good points there. At this point I'd really suggest dividing this thread to separate discussions about more specific features / areas of interest, though; this discussion is getting way too big to manage and keeps branching into all sorts of directions It's not about WordPress Though that's definitely not the core of the discussion here, the truth is that this has nothing to do with a specific system. WordPress is popular, so it's an easy way to address the difference between ProcessWire and many of the old school CMS products out there, but we don't hate WordPress specifically (well, some of us might). We do get annoyed when people jump in and start telling us what to do without considering that what we have now might be a well thought out product when it's just not what they expected. This forum gets regular posts from folks who jump in, take a quick look at ProcessWire, and based on that tout that "you're doing a, b, and c wrong, do them like system x".. or, more simply, "why can't ProcessWire be more like system X?". While some of the points they make are valid, they're missing the big picture, which is that ProcessWire really doesn't aim to compete head-on with some of those other systems. There's no point in that; it's the red ocean of web platforms. We don't want ProcessWire to turn into a site builder In it's heart PW is a tool that allows people to build anything they wish, exactly the way they wish. It's true that building sites with ProcessWire requires knowledge of how stuff on the web is built, and if you're looking for a simple "site builder" tool then perhaps something like Squarespace really is closer to what you're looking for, but at the same time the stuff already built with ProcessWire should be as easy-to-use for non-developers as possible. That's definitely something we should focus on, and if you take a look at what's been happening around here, you'll notice that we have been focusing on that (As a related note, I personally wouldn't be surprised to see tools like WordPress, as it is now, eventually die out in favour of site building tools like aforementioned Squarespace, or evolve into something very similar, while frameworks like ProcessWire will be needed much longer to empower those platforms.. but that's another discussion entirely.) You get what you give To get back to this topic, I'm starting to think that you're really not against all that. Your initial messages touting the death of ProcessWire, telling that it's only for developers, and pretty much stating out cold that those developers don't know shit about working with / for the end-user didn't exactly suggest that you "get this". Those comments took the discussion exactly to the wrong direction, so as a friendly tip, refrain from that sort of stuff and you'll get much better results around here. Many of us are designers, developers and people who've worked with a lot of of clients on a myriad of projects, and to suggest otherwise is just plain rude and provocative (and unlikely to yield the results you wish for) Extend ProcessWire, don't try to bend it The point is that as long as ProcessWire remains flexible and framework-y at it's core, none of us will be offended by modules built on top of that. That's the thing you need to keep in mind here: if you're saying that the core has to go to this or that direction, you're likely to face negative attitude. The core has a great direction, led by Ryan, and we're all behind that. In short, as long as possible try to keep the discussion in extending, not modifying, ProcessWire. The things you've mentioned, like admin themes, modules that do things out-of-the-box, packaging ProcessWire with things you need it to contain in your projects, integrating other tools, etc.. none of that requires ProcessWire itself to change. That's all you stuff you can build on top of ProcessWire, by extending it, and that's exactly because it is what it is now -- a flexible and non-opinionated platform form building just about anything (though mostly stuff that lives online). Also: I've built a CRM of sorts with ProcessWire, I've built a lot of application-type stuff using it, and most of my ProcessWire projects involve quite a bit of behind-the-scenes magic from integrations to imports and so on, but none of that will ever be described here as public examples, as they are not public per se. That's the "problem", really: most of the time we won't be able to show those things to others, even if we wanted to. They contain private information, and in a way they are private information. While you can tell a lot about ProcessWire simply by looking at the (public) sites built with it, that's not the whole truth. -- Now, please do discuss these things further -- none of us are against the discussion or the ideas, as long as you keep in mind some of the (hopefully understandable) things I've tried to point out here

@lisandi: I truly appreciate your enthusiasm, but clearly you and I see many things -- including what "success" really means, what ProcessWire should become, and what we'd like to do in the future -- in a very different way. Considering that, you may take my comments here with a grain of salt In a nutshell, I believe that there's a market for systems that do things differently, they don't all have to be WordPress clones, and they don't all have to do whatever it takes to become popular. In fact, I believe that trying to copy what others have done and doing what everyone is expecting -- and not thinking for yourself -- is what leads to "digging your own grave" in the long run. I don't want ProcessWire to ever become "the most popular system out there", even if it would mean "lots of jobs", if in the process it has to turn into something I can no longer respect and enjoy. I'm here exactly because I believe in what ProcessWire stands for. It's that simple, really. Those things aside, I think you've made some valid points, and we all have something to learn here. Out of interest (and assuming that I'm reading you correctly) you mentioned finding some interesting modules that aren't in our modules directory yet.. would you care to mention what and where?

Great idea, and I've got nothing against such a discussion -- in fact I'd love to see more of it. Still, a few comments on the specific points you've raised here: Our customers (i.e. end-users) have had very few issues with ProcessWire. In fact, ProcessWire is just about as easy-to-use as you can get. I've said before that as long as one knows how to fill in a web form, one has what it takes to update a ProcessWire site. Sure, improvements can and should be made when possible (and by no means do I want to stand in the way of any discussions about this), but to say that "ProcessWire is built with focus mainly on developers" is simply not true. On the other hand, I'm wondering if you consider installing modules something a person with "no programming knowledge" should be able to do? Part of your message seems to point to that direction, but please correct me if I'm misinterpreting you here. If that's the case, I'm not sure that I can agree -- modules that do things out of the box are a tiny fragment of all modules available from modules directory. Personally I don't consider that an important aspect, considering that we really don't want to be "the next WordPress" (or any other system that is based on the idea of building sites via stitching barely compatible collection of pre-built pieces together). Sorry, but no -- this wouldn't be great. Quite the opposite, really The whole point of the official list is to keep track of the quality of modules. I know there are modules out there that just haven't been added to the directory yet (and perhaps should), but in those cases the right path to take would be suggesting to the author that they submit their module to the directory. If they're not around to do that, that's a good reason to avoid the module altogether, as it's obviously not well maintained. Note: your idea of donation / sponsor button isn't bad, though. Not sure if that's easily doable (I'm really not familiar with such services and the way they work), but at least an option to add something like that would be nice. You can achieve this by creating new pages into Admin and moving pages related to installed Process modules under those, it's your call. Well-built Process modules won't assume that they're always installed in one location either, so moving them to another section shouldn't be a problem. .. although you're probably thinking of something larger here, and in that case, please do elaborate this further

Out of interest, do you have any details on the Bing and Yahoo parts? Google is obvious, but as far as I can tell, Bing and Yahoo still use keywords, though they're not exactly important ranking factors (quite the opposite, really -- they seem to have much less weight than regular body copy). Also, for anyone targeting the Russian or Chinese markets, it should be noted that Yandex specifically suggests using meta keywords (they're not revealing how important these are as ranking factors though) and according to some sources Baidu considers meta keywords "very important" (though keyword stuffing is a major negative signal there too).

@lpa: some of us definitely do, but.. apart from waiting for Ryan to react somehow to the issue at GitHub, or hacking up a solution (and sending a PR to Ryan) there's not much more to do, I'm afraid. I'd take a closer look at this myself, but honestly haven't had much coding time lately Ryan, if you're reading this: the issue is still there and still waiting for your input

For the record, this bothered me too. I get that many (most?) of your potential advertisers are CMS companies because you write about CMS', but.. if you ever write a positive review about a product that simultaneously pays you, even for something entirely unrelated, it's a bit like a politician voting "yay" on a law that benefits a large company while being connected with said company: even if it's honestly and purely innocent, it's going to send the wrong message. We're not the ones you need to convince about your impartiality, but that's just how it works. Making it very clear that you're only allowing these companies to advertise on your site and have absolutely no connections to them otherwise might just be the only thing you can do to "fix" this, though. The worst thing you could do would be calling them your "sponsors" (which seems quite common these days), but luckily you don't seem to do that As a bit of positive feedback, there's one thing you're doing absolutely right: so far I haven't seen a single paid or sponsored tweet on your Twitter timeline. My tolerance for paid content on Twitter is pretty close to zero -- in fact I recently unfollowed A List Apart because these days considerable amount (probably 10% or less, but still) of their tweets are spammy sponsor messages. Don't care how important they are, they're not that important.

@Zenophebe: what we have now in ProcessWire and how it's flexible and all has been explained in this thread over and over again. Hope I'm not confusing this any more than is necessary, but I'd really like to hear a bit more about some of your points: What is it exactly that you mean by content type here, and how does it differ from what Templates and Pages currently provide? Could you name a solid example of a thing that "can't be represented as a page"? Please don't get stuck on the naming -- Page is just a name for a content item in ProcessWire (imagine that we're talking about nodes, articles, resources, or whatever makes you happy) and Template is just the metadata that defines what kind of content it holds, and so on. Names have absolutely nothing to do with what these items of content are capable of doing. The examples in your first post ($page->body->author->name etc.) are what one would in ProcessWire, typically, achieve through page relations. In this case I'm having hard time understanding what exactly "body" is though -- is it a field or is body supposed to represent a section of page with content of it's own? Is it just a deeper hierarchy that you're looking for? Another way to achieve similar structure would be by using a fieldtype with more complex content structure. Table field (not to be confused with PageTable, though that's another option) would be an example of this, though perhaps not quite what you're thinking of yet; you can quite easily create fieldtypes with their own specific schema, and Table is a fieldtype that pretty much does this for you, allowing you to define the schema via backend GUI. Overall I think it'd be much easier for us to understand your point, if you explained what the actual problem / difference is, instead of simply stating that "this doesn't exist" or "this can't be done with Pages". The thing is that we can keep arguing about whether pages can represent different content types for all week, but it's not going to get us anywhere unless we're on the same page about what it means first. Also, if it's something that can be easily achieved using tools we have now, I'd suggest that you consider alternatives -- there's always more than one way to do things. ProcessWire is very flexible, and one can achieve just about any structure using it, but sometimes you will have to let go of your "one true way to do this" approach and consider using what the system provides. If you're confident in your programming skills, you might also consider building a proof of concept. If that's the case, I'd probably start by taking a look at the Page.php (this is the Page we're talking about here) and WireData.php (the base data container in ProcessWire, which Page.php also extends). A lot of what ProcessWire currently does is based on the idea that "almost everything is a Page", so you'll probably have to do quite a bit of work to get around this, but there are other content types already (such as comments), and it's absolutely doable. If you do build such a proof of concept, please let me know -- always interested in seeing new ways to do things, as long as they provide some sort of real benefit

Hi there, Fred. The answer to your question is "no", I'm afraid. You just can't build a site with ProcessWire without knowing any PHP, HTML, CSS, etc. at all. You can install one of the pre-built site profiles, though, if that's good enough for you. ProcessWire is a very good platform to use while you're learning these thing. If you're point is that you don't know these things yet, but would like to learn, then you're in the right place. I'd suggest browsing the net for some proper HTML tutorials first, though -- I'm in a bit of a hurry here, but I'm sure we can find something for you if you're interested. On the other hand, if you're saying that you don't know them and don't want to learn either, you'd probably feel more at home with a "website builder" than any actual CMS product. (I've heard good things about Wix and SquareSpace, but there are many others out there too.) Hope this helps a bit!

Not a bad idea at all, as long as it's approached with some common sense ("dashboard widgets" don't really make any sense in ProcessWire context, though if you want to, you can build entirely customised dashboard with ease, etc.) About the list above, there's a module for "Preview", and Version Control provides an "undo" type of feature, though I don't know what those exactly mean in Perch. Also, regarding cloud storage and backups, there's Schedule Cloud Backups and Amazon S3 Cloudfront (also related to the CDN part). Again, I'm not sure how Perch approaches these things, so this might be a different thing entirely

It's funny how it goes: in Drupal (almost) all content items are Nodes, which feels absolutely nonsensical and confusing to me, but I've never heard people say that they don't "get" it. Pages, on the other hand, seem to confuse many newcomers, even though the bulk of the content they manage in ProcessWire are exactly that -- pages. Personally I prefer pages over nodes, and perhaps even resources (from MODX)

Cloud hosting options make it relatively easy to set up even "per-client" environments, but a shared setup still remains a viable option. In the latter case you'll want to consider how secure it is, though, and what happens if one site is somehow compromised, under DDoS attack, etc. Probably the best advice I can give right now would be researching available options carefully and trying to be prepared for all possible (and seemingly impossible) issues -- consider it just a matter of time before they happen to you In any case, I wouldn't call it "like making money without doing stuff". Regardless of what kind of deal you make with the client (and perhaps another company that does the hosting for you), the client will consider you, personally, responsible if something goes wrong. This is also why you'll want to define very clearly what your responsibilities are, what kind of SLA you offer, how fast you'll have to react to issues, what kind of services you provide on a 24/7 basis, and so on. Oh, and trust me: being on call 24/7 gets on your nerves after a while..

Joss: glanced through this quickly, and so far I'm liking it. Your terminology is a bit "unique", but that's partly about semantics -- adaptive is actually not the same thing as responsive, etc. Apart from that, this seems like a very good starting point for someone with limited knowledge. Anyway, it's possible that I just missed it, but you might want to cover some common responsive patterns, especially navigational ones. That's one of the areas where even seasoned web experts tend to struggle. Google has some pretty awesome resources on patterns and a few other things you might want to check out for ideas.

@pwired: there seem to be a few misunderstandings here. First of all, if I suggest a specific platform, and explain my choice properly, and that makes the client lose her trust in me, I don't think there ever was any proper trust there. Just like Pete said, you just can't help everyone. About your other point, I never said that the project is doomed if the client decides against ProcessWire. I said that the project is probably doomed anyway if the client doesn't trust me and my expertise. There's a huge difference there. If a client approached me and told me that she needs to put a static one-page flyer online, I wouldn't spend a whole lot of time explaining why that flyer should be built using ProcessWire. I'd go with a static page and that's it. Also, if the client requested a huge e-commerce site, I would probably explain that there are other solutions, including various SaaS products, that probably match her needs better. Being an expert doesn't just mean that you can convince anyone to buy anything. It's about finding solutions, and sometimes the right solution is to let the project (or the client) go

@pwired: I communicate with clients regularly, and the clients I work with tend to understand common sense. They don't have to be professionals to understand that system X might not be the best choice for them because a) it's not scalable, b) it's not secure, c) it's not powerful or d) it's going to be bloody expensive. The client does have to trust my word as an expert, though.. and if there's no such trust, the project is pretty much doomed anyway

Someone else might have a better solution, but the options I can think of right now would be using a "dynamic" RewriteMap -- or a static one, if it's possible to list all the URLs available at the legacy site. On the other hand, if you end up with a dynamic RewriteMap, I'd probably go with a simple module that hooks into page not found and checks there if the requested URL exists, perhaps combined with some sort of internal caching Either way, using this kind of approach you will need to perform an additional query behind the scenes to see if the URL exists. While that's doable with -U in mod_rewrite too, it doesn't handle 404's (or, rather, it considers them "existing URLs") so it's not really useful here AFAIK.

The main "selling points" for ProcessWire I've used in the past are flexibility, cost-effectiveness, security, performance and scalability. The order depends on the client and his/her specific situation, but there's always something you can use: If the client wants something large or very specific but doesn't have an endless amount of cash to spend, ProcessWire is a very good choice, as it has built-in a lot of common features and the rest (ones that probably won't fit any pre-made solution anyway) are usually much easier to build than with certain other systems. If the client isn't entirely sure about his/her needs and/or those needs might change in the future, it's good to explain that with ProcessWire there's always room for growth. I've never, ever said "ProcessWire can't do that" (and probably never will). ProcessWire is secure, period. Zero known vulnerabilities, built-in CSRF protection, various security measures against things like cache poisoning and session hijacking, *almost zero possibility for SQL injections*. With or without the buzzwords this should be of interest to the client regardless of their technical know-how. ProcessWire comes with a whole collection of native caching methods and has pretty awesome level of performance even without any caching at all. If the client is worried about how the system will hold, toss in ProCache (or simply mention that it's easy to setup later if such a need comes up). I've managed sites with tens of thousands of pages and I know that there are a lot bigger sites than that. I'm not sure about EE, but I wouldn't even dream of doing something like that on certain other systems. Not sure if this really applies to your client in this case, but it's good to keep in mind anyway ... and, of course, there's the "it's 100% open source" thing. Many clients seem to value that nowadays.

Gamified CMS. Cool