teppo

@Christophe: main reason for the anchor weirdness is probably that the anchor feature of CKEditor was built a very long time ago and has pretty much remained intact since then. "If it works, don't fix it" -- and so on. Extra attribute (name) is actually still in use (even in HTML5), though <a> element doesn't have this attribute, so it's technically non-standard here (though non-harmful too). If current anchor behaviour is bothering you, it might be easier to find a CKEditor-specific solution to this issue from StackOverflow or the CKEditor forum. Based on some quick Googling I couldn't find an obvious solution to this, but that doesn't mean that there's none to be found. Anyway, I'd just go with custom CSS to target headings with anchor links (like you've pointed out yourself)

@Christophe: that's probably because ProcessWire, in this case, sets width and height attributes, not styles. Assuming that the terminology in CKEditor docs is correct and they're not actually referring to attributes, of course. About your <ul>-issue, including ul(classname) should definitely work. What does your entire Extra Allowed Content setting look like -- I'm assuming that this isn't the only thing there? Also, please double-check that you're editing correct field etc. Sometimes it's the small things..

@douglas81: you're right, at least the duplicate module issue is because these have moved to core modules (/wire/modules/). The most sensible option for duplicate modules would be removing them from /site/modules/. If you've got customizations to the CKEditor config.js or custom plugins you're using, that'll require a bit more work (essentially you'll want to place them in your /site/modules/InputfieldCKEditor/ and /site/modules/InputfieldCKEditor/plugins/ directories, respectively). The problem with Thumbnails modules (images with cropping) might be related to the issue I've described here. There's also description of what I did to fix it in my case. Seems to me that Antti hasn't fixed it in the module itself, so you might also want to drop him a note in that thread.

Thanks for the heads-up, adrian -- I'll definitely consider that. I'm using PageTable a lot these days too

@totoff: Generally speaking I'll have to agree with you on the point of ProcessWire growing all the time (no doubt about that), but I'm still very interested in looking for ways to speed that process up and really don't think that we're in a situation where we can simply lay back and wait. Though it is often fun to explain to new, open-minded people how ProcessWire works, I don't particularly enjoy defending my choice of platform to people who counter every single argument with "WordPress is more popular, so it must be better". Sure, we're unlikely to be more popular than WP (and I'm not really looking for that either) but to certain extent being better known (and more widely used) should help diminish the value of such arguments

In some ways this discussion still keeps going in circles. "We want to have more site profiles / markup modules / modules in general for beginners" vs "ProcessWire is awesome for seasoned developers and we don't want that to change". Quite frankly it's still not an either-or choice; ProcessWire is extendable (modules, site profiles, templates) and we can -- easily -- cater for both sides. We've got a lot of good ideas floating around here. We know that we need to actively promote ProcessWire and we also know that we need to provide more resources and tools for users of all levels. What we need more than anything else right now is, in my opinion, more action. For this reason alone I have enormous respect for projects like ProcessWire.tv, Cheatsheet, Captain Hook.. and all the people writing blog posts, tweeting and otherwise helping to spread the word. That's the kind of thing we need if we ever want to be noticed by wider audience. I also think that catering for (ProcessWire) beginners is where we're currently a bit weaker than we should be. We need more easy-to-use modules that make common tasks trivial and -- especially -- resources that help people get acquainted with ProcessWire. I'd also love to invest some time in creating site profiles performing specific tasks; I for one have learned much of what I know through the process of taking things apart and, when I'm confident that I know what makes them tick, modifying them to better suit my needs (a process also known as hacking). That's what I see as the biggest benefit of extensive site profile library, by the way -- it's definitely not about us having everything thought out and ready to install, it's much more about us having a good starting point for a wide range of things.. and a lot of raw material to bend and twist and study as one sees fit. For the record, one thing I've been kind of disappointed about is that the more I discuss things like CMS' with people making the decisions (or helping others make the decisions), the more I see how much they value safety. Such safety is generated by long track record, popularity and sheer numbers (end-users, developers, modules, extensions, etc.) This makes a lot of sense, really, but it's also a bit annoying when you're rooting for "the underdog"; in order to get larger audience you need to have larger audience..

This sort of thing is rather easy to set up using mod_rewrite too, and if there's a lot of content, that's often only sensible option. This thread might be of help to you, the problem is essentially the same. Note, though, that you should be careful with 301 redirects -- since in theory they're "permanent" browsers can cache them for a very long time. For temporary, short-term solution use 302's instead.

@SiNNuT: I can see the option to leave .htaccess untouched, if thats what you're referring to. Not exactly the same thing, though -- more like diff/merge, perhaps? This is a file that's intended and/or sometimes needed to be customised per site, so this would, in my opinion, make sense

Ryan: this looks really cool. Haven't tried it out yet, but it should be useful, especially for my own projects I was wondering is if you'd consider adding a check for potential issues with 3rd party modules, i.e. if there's a module that hasn't been marked as compatible with the new version? As far as I know, this info isn't cached locally (at least at the moment), and not all 3rd party modules are in the modules directory, so it might get complicated, but it'd be nice to see a list of modules that could potentially cause trouble before updating. Another thing I was wondering was whether it'd be possible to somehow handle intended additions to files such as .htaccess. If one has added own caching rules or something like that, it'd be cool if the upgrade process could keep those intact. This might require a pre-defined way (or place) for specifying such things, though, so perhaps it's not feasible..

ProcessWire uses quite basic RBAC system and it probably just didn't feel necessary to dive further into this. Some of the basics: Each user has one or more roles; "guest" is always assumed and required, even for non-logged-in users (i.e. visitors) Each role is a named collection of one or more permissions; page-view (as you noted before) is always assumed and required and only displayed because, well, it's there (that's actually supposed to be helpful; you don't have to guess which permissions this role might have, what you see is what you get) Permissions are just permissions, there's nothing really magical about them; for the most part they're just Pages with special purpose Each Page uses a Template and each Template has access settings, where you can define which roles have access to the basic actions on Pages using said template: view, edit, create and add children One important thing to note here is that an user having a role with page-edit (or page-view) permission won't instantly allow that user to edit / view all pages but it is a prerequisite for giving this kind of access at Template level (via access settings). Template level access settings are just one use case for the access control system in ProcessWire; it actually goes a lot further and is much more versatile than that. (Admittedly this part does sometimes cause confusion and thus it might be worthwhile to document it more clearly.) Programmatically managing and/or checking for roles/permissions is explained in the docs. If you want to check if user has specific permission, whether that's built-in permission or one you've added yourself, it goes like this: $john = $users->get("johndoe"); if ($john->hasPermission("read-the-docs")) { echo "Sure thing, go ahead: http://processwire.com/api/"; } Cheatsheet also provides basic info on most (if not all) actions you can perform on/with users, roles and permissions. If you use $pages->find(), it should already only return pages that current user has view access to (unless you add "include=all"), so I'm not entirely sure what you're referring to in your last comment. Pages don't have roles, they have a Template, and that Template has access settings. If current user doesn't (via one of her roles) have access to view that Page, it won't be returned by $pages->find() either. Note: $pages->get() is different from $pages->find(), as it assumes you really want that one, specific Page. It always returns the Page (if it exists) without considering permissions.

Almost. There's also an additional check to see if the returned page contains certain traces of ProcessWire. Simply checking the return code wouldn't be enough here For the record, isit.pw includes roughly a dozen methods for checking if a site is running ProcessWire. In many (most) cases it can still identify your site, even if that one check fails. I should probably mention that isit.pw (which is my project) is both a functional tool (as Antti explained earlier) and an experiment; "can you properly identify a site running ProcessWire or not?" I'm also planning to add an info section later, including details on hiding your ProcessWire-ness from humans and services like isit.pw equally

Thanks, Adrian. I've just fixed the notices you mentioned earlier and removed the stray </em>. View Page seems like a worthwhile addition, but at the same time it makes the UI feel a bit stuffy. I'll have to give this a bit of thought