ryan

In your admin, click "Access" and then "Permissions". That shows you all the permissions currently in there. When editing a role, you can check the boxes for the permissions allowed for each role.

Technically you can, as those paths are defined in /index.php and nowhere else. I haven't actually tried it since PW 2.0 pre-release, when I was experimenting with different defaults. Though ProcessWire was designed to be "invisible", as much as possible, so the intention was that people who needed to change that stuff, could. If you do change those, you have to be aware of upgrades to /index.php as Pete mentioned. But you also have to be aware of the .htaccess file, which has those paths hard-coded (as they have to be). You would need to replace references to "site" and "wire" in that file with whatever you had renamed them to. And you'd want to double check that all the security blocking access to the directories was still working correctly. When ProcessWire gets big enough to be something that automated tools would be hunting for, then we'll take this further with real testing and documentation on how to completely disguise your site. But I think it is kind of wasted effort at this point in time. Meaning, I would avoid changing your /site/ or /wire/ directories.

You could just perform the translation from its final location, rather than it's temporary location. But the truth is that anything that allows one to upload code or files that will be executed on the server is considered a security hole. It's true that it's probably fine if you are the only one that can write or upload that code. But it's also far from a best practice, and ProcessWire is written towards enforcing best practices, which is why it's not making it easy here. One way to do it that would be workable would be to keep your files in the original location (off /site/templates/) and use your fields to refer to them rather than pull code from them. For instance, you might have a text field where you type "projects_page_promotion" in it, and your template file automatically includes the file matching the name in /site/templates/snippets/sidebar/content/. To take it further, you could make it a Page reference field, so that they could be selectable and even draggable/droppable (via an asmSelect field). Let me know if I can describe more detail on that. There are all kinds of possibilities here. But it would require you to maintain the best practice of keeping the actual code out of your site's content and as part of your site's development files.

No, but I looked it up and read some info about it -- sounds like a great one. I need to check it out sometime.

That is awesome! Wish I wasn't being called down to cook dinner right now, I can't wait to try this out.

No I think WillyC has some insight here. A page tree can be a type of fractal, which is what I think he's trying to show with that image. And the man is presumably creating and manipulating the tree (fractal) as you would in ProcessWire. Translation: the nature/secret of categories is that they are just pages. world=your site, catpage=category+page. So your site is made of categories or pages, and the distinction does not matter as it's all the same. Translation: Once you know the true nature of pages, you can create anything. Self actualization or something? Do I have this right WillyC?

The nice thing about threaded comments, from a development standpoint, is that they are easy to achieve. They are the same as regular comments, but with the addition of an optional "parent" for each comment. So one could take a flat comments system and make it threaded, without much effort.

Soma's correct with this. But minor point: $t = new TemplateFile($config->paths->templates . "./{$page->template}.php"); That "./" would probably prevent it from working. It should probably be: $t = new TemplateFile($config->paths->templates . "$page->template.php"); Or if you are doing this already from a template file (script is already in /site/templates/): $t = new TemplateFile("./$page->template.php");

Okay I got it. Well, I don't know why the repeater items wouldn't get deleted, but will experiment here to see if I can reproduce it. You might also double check that none of these pages are actually in the trash, rather than deleted. You could also try out the dev branch, but I'm not yet aware of an issue with repeaters in 2.2.9, so not sure that's worth trying. I'll see what I can find here.

This was a bad practice years ago. Correct me if I'm wrong, but this is not a bad good practice now, at least if you want to support high DPI screens? I mean if you go inspect the ProcessWire logo in the upper left hand corner and open it in a new window, you'll see the actual image is much larger than it appears on the site. That's the only reason it looks sharp on a retina screen. Yes, this might make it look bad on IE6, but well… if you are using IE6, life is already a bummer. The purpose of specifying one dimension with the <img> tag and using an overflow:hidden for the other is to prevent any stretching of the image (maintain aspect ratio). I've not personally used this technique, so not speaking from experience. But it seems so simple that I'm inclined to try it. Unless you are talking about upscaling an image (I'm guessing not) then it just means you've got to start with a bigger crop, in terms of physical dimensions.

Content delivery network, like Akamai (and Amazon too, you are right). I've developed several sites that do it. It's also supported by Form Builder. There's really not much to pushing data to Salesforce though, they make it pretty easy.

CMSs like WordPress and Drupal generate markup and as a result shamelessly reveal themselves all over the place. I don't think there's anything you can do to completely hide that something is running on WordPress, for example. And I don't think you'd even want to bother trying, because the people that can do real damage can identify WordPress and other platforms in so many other ways that go beyond just output. ProcessWire hides itself quite well, as it generates no markup and lets you hide your administrative page wherever you want. The only way I know of to identify a site running ProcessWire is by looking for things like "/site/assets/files/" in paths to images. Like with any system, another way is to get familiar with the directory structure and start trying to request files that are known to be protected and see if you get the expected HTTP error response code. Should someone choose to name their /site/ and /wire/ directories something else (and update their /index.php to reflect it) then I don't know of any way to detect ProcessWire from the outside. Though ProcessWire is not yet "known" enough to be a target for any of this. Automated hacks are looking primarily for WordPress, for the same reason that most viruses are written for Windows. And most of these hacks are targeting vulnerable versions of WordPress plugins and themes, since WordPress itself is fairly secure by now.

Joss posted at the same time as me, so I missed his post when I was writing. But he makes excellent points. You should expect the site to be under attack when it gets popular. The more you can separate the tasks of the site, the better off you will be. Even if your site is totally secure, you can expect DDOS attacks, and dictionary attacks to any login forms, among other monkey business. Keep your community, main site, CRM, store and e-newsletter each separate and quarantined from each other. There are plenty of things you can do to make a site "look" integrated, without having them run side by side. For instance, you'll see the PW main site referencing latest posts in the forums, and it just does that with the RSS Loader module. Most good systems and services can talk each other these days, in a secure manner. So they don't need to run together.

Welcome to the ProcessWire forums Carlos. Good idea. Even better might be to go managed dedicated (like what we're using here from ServInt), or one of the platforms that can scale like StormOnDemand. Drupal and WordPress = Republicans and Democrats It should handle massive traffic better than most. It's certainly lighter weight than the others you are considering. ProcessWire performs very nicely without any caching features turned on. But as your needs to handle higher traffic increase, you'll want to take advantage of more caching features. ProcessWire includes some very nice full-page caching features (controlled in the template settings), and partial-page caching features (controlled by the MarkupCache module). I am also working on a so-called "Supercache" that completely bypasses the PHP/MySQL and enables delivery of high traffic pages as quickly as plain HTML files. This is not yet ready, but is in the works. Beyond caching, you may also want to move your static assets (CSS files, JS files, image files) to a CDN, so that your main server doesn't have to do anything other than render and serve markup. I have not personally had to manage a site that needs to deal with CNN mentions, so I'd recommend calling ServInt and asking what they'd advise, as they do host a lot of high traffic stuff there and know what's necessary. They are in the DC metro area, and have both DC and NoVA data centers, so are experienced with high traffic government/political related sites as well. While you can make ProcessWire do just about anything (and it'll make a great CRM), I would suggest keeping your website focused purely on delivery of web pages and use SalesForce (or something else) as your CRM. ProcessWire will integrate easily with SalesForce, at least with regard to submitting form data into it. Given your potential traffic considerations, I would probably separate your main site from your state party websites. Perhaps run all the state party websites from a separate server or VPS, and enable either to be a backup for the other. Stick with MailChimp. Don't bother with a built-in newsletter module from another system. This will save you from having to deal with a lot of annoyance, server, DNS and potential blacklist issues. In my opinion, the currently available forum software (especially the one we're using IP.Board) is so good that I wouldn't even consider a CMS forum add-on from EE or the like. IP.Board provides lots of API connections that can be used with ProcessWire. Pete (our administrator) has has written modules that connect IP.Board with ProcessWire. They are not released, but are in use on his site and will eventually be in use here as well. The only reason they aren't already is just that there isn't a lot of crossover between what happens in the forums and rest of the site here, so we're finishing the site redesign before doing it, but will get done. Perhaps Pete could reply to explain a little more about what's possible between IP.Board and ProcessWire. Much of this is also possible with IP.Board. Ultimately though, your users are going to still go to Facebook regardless of what you setup. So I'd focus on Facebook integration more than BuddyPress. I highly recommend Shopify, should you want to step beyond the donation form to sell other party items. BrainTree is an excellent merchant account/gateway to go with it (and avoid PayPal, obviously). This is a lot simpler and more secure than trying to self host. At least in the US, the laws/rules (PCI compliance) governing servers involved in any kind of data collection as it relates to transactions are something you want to let an expert provider run for you, unless you want to spend the rest of your life doing nothing but PCI compliance. Btw, since you run that Justice Party site: very attractive site, but took me awhile to get the message. I was sure this was something tea party related, until I saw the nice table on this page that clarified it all. Might be nice to see that table, or some variation of it, right on the homepage. I would bet that it would decrease the bounce rate significantly.

Form Builder will always work on whatever the current version of ProcessWire is. The current Form Builder versions work on either 2.2 or 2.3. Though Form Builder, like most ProcessWire modules, are very likely to keep working just fine, regardless of version. All Form Builder versions include 1 year of support and upgrades. The only reason to go for the 'dev' version would be if you planned to install it on some unknown quantity of sites you develop over that year (as there is no limit). Whereas the 'pro' version is for 3 sites, and the 'single' version is for 1 live site. But all include the 1-year of support and upgrades. You can always go for the 'single' or 'pro' and later upgrade to the 'dev' (we just subtract what you've already paid from the total, when you upgrade).

If you upgrade to 2.3 now, you'll just want to test everything in your site out to make sure it still works how you expect. There have been some core changes and optimizations that should not change any behaviors, but sometimes small things don't become apparent until it's in broader usage. So just test thoroughly. Also note that once you've got 2.3, you shouldn't go back to 2.2. It does make some minor DB schema changes in some cases, which 2.2 wouldn't know about. It also uses a different hashing mechanism for passwords that 2.2 doesn't support.

I'm still confused about why pages are getting deleted as part of the migration. You mentioned in your first post that you were getting the error message when adding a page (presumably on the production server?) but in your post directly above it sounds to me like you are referring to an error instead on the staging server, where you were deleting the pages? Apologies for my confusion. Can you abstract your question further, perhaps take it out of this specific context. For instance, I've wondered if your question is this: "When I delete a page with repeater items, the page gets deleted but the repeaters don't. Why?". If that's your question, can you tell me which version of ProcessWire and what other 3rd party modules are installed?

I think that you can do this all with CSS. Once you've got a crop, you can automatically CSS position it within a markup container (that has overflow hidden) to achieve variations like those you mentioned. That is, so long as the crop is something smaller than the original. You could go about it either using an <img> in a <div>, or just a <div> with a background image. If you need to just scale, or scale and crop, you'd probably want to use an actual <img> tag that specifies either the target width OR height (not both) with the other dimension overflow:hidden by the container. If you are supporting high DPI/retina displays, you are probably already doing this to some extent, in terms of the scaling aspect.

Great work! Thanks for making this. I have updated your modules.processwire.com listing to include the screenshots too.

I am confused about how your includes are being done. You mentioned you are using a File field and including them, which sounds concerning from a security standpoint. But the snippet you mentioned (/site/templates/snippets/...) is not in the path where file uploads go, so I'm confused on that point. As for why they aren't translating--have you specifically translated them? By that I mean, did you go to Setup > Languages > [some language] > Translate New File > Enter filename: /site/templates/snippets/sidebar/content/projects_page_promotion.inc ? If you have translated them, then the translation will only work so long as the file stays in the location that you translated it from. That location is called the "textdomain", and it's the primarily way that set of translations relates to a file. So if you translated the above file, and then uploaded to your site somewhere else, it would not continue to be translated.

Anything is possible. In this case, someone would create a plugin module to do it. The existing Comments module would probably be a good base to build from, for that particular need. The Discussions module may be similar. Since it is built on Pages, any other fields (like rating) can presumably be added without much trouble. The Comments module could also be extended fairly easily to support threaded comments (with some development). Though personally, I'm not a fan of threaded comments... the only one I've found tolerable is Disqus.

This doesn't not already exist. But it seems like a good idea for a module.

You could also look at it from the point of view that almost everything is (or at least can be) a category. Not a blank slate at all. In my opinion, traditional categories are very limited. And I always struggle with that when using other systems.

If you don't specify a permission, then your module is available to all admin users. If you specify an existing permission, like 'page-delete', then your module's execute() method(s) will only be available to users that have that permission. You can also have your module install a new permission, and then set it as the required permission. Example: $p = wire('permissions')->add('page-draft-control'); $p->title = 'Ability to create draft pges for edit/preview'; $p->save(); I think that the above is probably not exactly what you are looking for. In your case, you are using a Process module as an 'autoload' module, so your hooks are getting attached regardless of any specified permission (since that permission only applies to 'execute' methods). What you should do is check that the actual $page is editable() before performing runtime actions: public function hookPageListActions(HookEvent $event) { $page = $event->arguments[0]; if(!$page->editable()) return; ... } public function executeCreate() { $page = $this->pages->get((int) $this->input->get->id); if(!$page->id) throw new WireException("Page doesn't exist"); if(!$page->editable()) throw new WirePermissionException("You don't have access to edit that page"); ... }

You are right, we could probably use a section on the Page fieldtype here (among others). And a "how to create categories" guide/tutorial makes a lot of sense. I think we had one in the forums at some point, but think it's buried somewhere. Personally I learn best from examples, so that's the way I tend to communicate too. The Blog profile is a great example of the Page fieldtype in use for both categories and tags. Though it only uses them as flat (not nested) categories. The skyscraper profile also demonstrates the Page fieldtype, though not necessarily in the category context. We definitely need more written content in this area.