Pete

The problem I think is that for the individual page permissions you might not always want it to inherit so it can't make that assumption. It could do with an additional option for it though of course - not sure how easy that would be though as whilst it sounds like it would be a case of recursively applying it to children, grandchildren etc, if you create a new child page it wouldn't inherit the parent's permission so it's not that straightforward. I always do it with templates in the end as there's more control that way. For news I have a news_home and news_article template and approach each section this way as you would usually want different things in different templates for those sections anyway. Even if you don't it's possible to clone a template in the admin and you just rename it and you're sorted

I think the preferred method is actually: if ($page->files->count() > 0) { Though I can't for the life of me remember why there was a performance benefit to using PW's method above, I'm sure there definitely was one... possibly because the count is already part of what's loaded into memory in the PageArray and you're not counting things again unnecessarily. Or I could be talking utter rubbish. Who knows

The trick with counters is to remove yourself from skewing the count. I find that when writing blog posts I load the page several times and this would increase the count several times. You could go a step further with diogo's code and do this to exclude your account (superuser) from increasing the count: if (!$user->isSuperuser()) { $page->counter += 1; $page->of(false); $page->save('counter'); $page->of(true); } echo $page->counter; Or you could do the same for multiple roles if you have different editors for your site (my example has some fake ones named "news" and "sports" below): if (!$user->hasRole('news') && !$user->hasRole('sports')) { $page->counter += 1; $page->of(false); $page->save('counter'); $page->of(true); } echo $page->counter; Just a thought

If tag_seasons is a page field as you say and "spring" is the name of a page in this case then you could do: $theseones = $pages->find("tag_seasons.name=spring"); I'm not sure whether it makes the search faster, but something I always do out of habit is specify the template as well (someone cleverer than me can clarify if it is beneficial, but I think it helps with readability of the code as you know at a glance what type of page you're expecting to get via the selector): $theseones = $pages->find("template=youretemplate, tag_seasons.name=spring");

Whilst I think they will still be able to see other parts of the site tree, this will allow you to apply edit permissions only to specific pages and manage it that way: http://modules.processwire.com/modules/page-edit-per-user/

@OrganizedFellow - fixed @horst - this is on the Mobile template and now you mention it it does seem odd! I can't say I had noticed it before though. It should be possible to change this, but I will check with the devs of the forum software to see if they are rolling out an update anyway as you would think that the desktop and mobile versions should be consistent with topic links.

Great minds think alike: http://processwire.com/talk/topic/2374-batch-allow-template-edit-access-to-new-role/#entry22423

I think this is what it all boils down to. The API actually means you're not altering/editing/refactoring any of the core code of ProcessWire. All modules simply leverage the functionality of the API rather than modify the codebase and I think that helps you get out of those grey areas. Section 2 of the GPL is where a lot of confusion stems from I think, but it refers to modifying the core program (ProcessWire) and your modified work then needing to be licensed under GPL rather than modules. I think these two paragraphs definitely apply to modules since they don't alter core code or copy core functions, but are in fact original works that simply reference the API functions so are exempt from section 2 as far as I can tell: The way I've read this, you aren't required to distribute commercial modules with a GPL2 license and actually shouldn't otherwise others can redistribute them freelyunder GPL2. Looking at the FormBuilder module readme.txt file ryan has wisely not distributed it under GPL. In fact after looking at the code he has gone to some lengths to ensure that all code for FormBuilder is packaged with that module and isn't borrowing bits of code from the source of ProcessWire itself, so as with other modules it simply interfaces with ProcessWire via the API and leaves the source alone. Going back to the last paragraph I quoted at the start of my post, ryan is also quite correct in that you use the API not only when building modules, but also when building the templates for a website and you are not expected to have to redistribute your website under GPL so I don't think it necessarily applies to modules either since you are using the API the same way in both instances (for those that don't know, you could easily recreate the functionality of some modules inside templates and the code would be identical in places - it's just neater having large chunks of code in modules where appropriate). I think my train of thought has arrived at the station. Not sure it all made sense, but from what I understand ryan has been quite clever with the API in that it grants quite a degree of flexibility when it comes to custom modules and licensing.

There are a few issues here that I think have been discussed before - the settings tab for a page also contains the page name field /your-page-name/ so you can't really do without it (what if a client changes a page title completely after creation for example? The page name won't update itself - and rightly so as it is the URL so you don't want to assume that the URL should change itself if that URL has been indexed by search engines). It also contains the visibility settings for the page, so if they accidentally publish a page instead of leaving it hidden after save then they would have no way to un-publish it again without that tab. There are also things like template selection in that tab that can be useful to editors/clients... in fact, everything on that tab could be useful for an end user I don't think it should be able to be hidden, but rather the end user should be informed what the features there actually do.

Hey Ollie There are a few MODx Evo developers here including myself. Are you able to give a bit more info about the projects in question? You can contact me via PM if you like.

I like that he hasn't even specified valid code, just gobbledygook code - surely this means you can just mash your keyboard for a few hours and pass it over?

I've read a few Larry Ullman books and loved them when I read them - easy enough to follow

Let us know if you run into any issues or need to ask how to do something the "PW way" - usually you'll get a quick response and that certainly helped me transition from MODx to PW a few years ago

I believe he means Deutsch site, which loads fine for me. That or he wants to populate douche.processwire.com?

The only thing I would add to this idea is that, whilst it's possible to achieve, if you were aiming fir millions of users and many page relationships you would soon rack up a large database so would need to make sure that your PW selectors are well optimised and that your server can handle the traffic. Technically it is possible but if it takes off and you're aiming at tens of thousands of users or above there are some other considerations is all I'm saying

Also worth noting is that porl has created a Twig module here: http://processwire.com/talk/topic/1421-twig/?fromsearch=1 and there is a Smarty module somewhere on the forums recently too so you could try both of those out. I can't see either being the default though because the system is designed to make few/no assumptions about the end user, but there are a few options there at least

This isn't meant to disagree with what you've just said, more just understand the processes people follow when working in teams. Why would you let your designer work on templates in your final system at all? The way I do it when working on my own sites is to build templates separately and then copy and paste the HTML into the ProcessWire templates, which to me seems sensible over letting a designer do tweaks on the actual system. Where I've worked in a team this was also the preferred way of doing things - the dev would be the one to actually insert the final HTML into the template files. This is definitely more about me not knowing other people's processes than anything else though so please do weigh in with your experiences. The other thing to bear in mind is that even with a templating engine they could still type PHP into the template files so it wont stop them, but on the bright side if you don't tell them they can then they're less likely to do it And welcome to ProcessWire Anthony.

I wonder if that is a recursion issue.

I've done it with a few MODx Evo sites too and plan to convert more when I have time, but mine were only up to a dozen pages in that case where it's probably easier just to copy and paste the data once you've got the structure sorted in ProcessWire. Like SiNNuT says, if you give us more details I'm sure we can help further.

This should all be sorted now and, although you won't spot any cosmetic changes, some of those bugs people were encountering should be gone as well (fingers crossed!).

Okay, the editor is back again so we can use the forums (hurrah!). Here's a quick update - I've had to hardcode a setting into a JS file to get it working, so looking through various things and the fact that there are still a few invisible errors behind the scenes I think there's something wrong that's taken hold during a past update and each update is making it slightly worse. As such, I'm going to pass it over to the devs to look into now to see if they can find the cause and sort it out. In the meantime, I don't think any of the other errors people have been reporting will have been fixed, but nor should they hopefully be any worse. In short, the core code is up to date and we're all secure, but the user experience is no different than before until I get to the bottom of this.

REALLY infuriatingly something has gone wrong again with the editor. It works locally, it doesn't after uploading. I'm trying to find the cause of the issue and at least get the editor working, but somewhere between my PC and the server something goes haywire For now, if you really want to post, switch to the mobile theme whilst I work this out. Once I've got the editor working I'm passing this over to the software devs as it is frankly doing my head in now that it works fine locally and then messes up on the live site every time. It's not just the editor though, a host of javascript issues are present no matter how many times or in what mode I re-upload the files.

Hey folks, I'll be updating the software and applying the new theme again in about 20 minutes time, so hopefully this will fix the various issues people have been encountering once and for all. Failing that we could always switch back to the alt.fan.processwire newsgroup as those things used to work consistently (yes, that is fictional ).

Why would you want built-in FTP though and why would it be a big-ish caveat? Use an FTP program for FTP Brackets does look awesome though.

For encycolpedia, see Wikipedia 0.1 alpha.