ryan

We'll start simple. The only things that matter much to me for the core inclusion are just getting it to the point where we don't have to worry what happens as scale increases. Though since the modules manager can upgrade itself, even this may not be crucial. I'm thinking it'll still live in /site/modules/ModulesManager/ but just be included with the default profile(s) distributed with PW, on the file system, but uninstalled. Once we've got it as an integral part of the Modules tab, then it would always be installed, but that can come later. I also think we've got to have even more disclaimers in there, warning people about the dangers, especially on a production server. The reality is that should one of our module authors turn to the dark side, they could take control over any sites running their module by just inserting malicious code and updating the version number. The next time someone updates, bam! Beyond just warnings/disclaimers, we probably need to pursue a "verified by ProcessWire team" label for quality assurance and safety. But this is longer term... Of course, will always support that. I agree. It might have sounded good at one point, but I don't think we need that either. Rollback would be nice to have in the longer term. In the shorter term, I think it would be adequate to say "Warning: Installing new modules can break your system. You should always backup your database and /site/ directory before installing new modules or upgrading existing modules." I will update the module dependency system to support specification of required version of modules. Currently it just lets you specify required modules. Since PW itself won't install modules lacking dependencies, I don't think the dependency system has to be built into the modules manager at this stage. Good point. Modules Manager should not probably not consider version number at this point in time then. Especially since once a module works in PW, it tends to usually work in future versions. Required PW version won't be a factor initially, since Modules Manager won't be included until 2.3 dev or 2.4. We can just refer to these versions as "known working with" versions.

I think it's a good approach going forward to keep big modules like this out of the core. But doing it now with TinyMCE could create some real upgrade challenges for folks. The TinyMCE module is also a bit of a different animal in that it has a couple of supporting modules in the core as well: ProcessPageEditImageSelect and ProcessPageEditLink. At present, all the site profiles we distribute also use TinyMCE. I think by the time we hit PW 3.0, we'll be at a point where we can look at excluding it. Ideally PW of the future comes with nothing but the absolutely essential core modules, and I think it'll be possible in the future (especially with modules manager as a core module). But right now ease of setup and upgrades takes major precedence over file sizes, as we are still an largely unknown CMS trying to grow our audience.

Check your /site/assets/logs/errors.txt to see if you can get more details about the error that occurred. A PHP version change really shouldn't matter for this, but I'm wondering if the 5.3 and 5.2 are running from different php.ini files with different restrictions.

No, if portfolio_image is referencing a single image, then accessing ->first() would likely produce an error unless the page has output formatting turned off. That output formatting state (ON by default on the front-end of your site) is what makes an image field with a "1" max images behave as a single image rather than an array of them. This is supposed to be for convenience, but has been a common point of confusion. I'll probably add a setting in there that literally says "Do you want it to behave as an image or an array from the API?" <?php if ($page->portfolio_image) { $image = $page->portfolio_image->first(); The above code example was in one of the previous messages, but is not correct. If it's an image field that can contain multiple images, then $page->portfolio_image is always going to be an array (WireArray). Meaning "if($page->portfolio_image)" would always return true, even if there were no images in it. This is just the way PHP works. As a result, you'd want to code it instead as: <?php if(count($page->portfolio_image)) { $image = $page->portfolio_image->first();

I use one called IShowU (for OS X). I've had it for awhile, and it wasn't free, but it was cheap. Seems to work well. Though I'm not particularly good at making screencasts, so usually end up editing it in iMovie before putting it on YouTube.

I just released the new version of skyscrapers profile within the last week, so it's the only profile that requires 2.3. Because 2.3 isn't actually released yet, it's the current dev branch of 2.2. You can get there by going to our ProcessWire GitHub page, click "branches" and choosing "dev". From there you can download the zip of 2.2.12 aka 2.3.

This is the plan. We just need to find a way to integrate it all and make it scalable and I look forward to working with Soma on this if he's agreeable to it. I don't think the current method of displaying all the modules on 1 screen will be sustainable as the directory grows. Plus, if/when ProcessWire gets really popular, the server probably won't be able to handle the load. I'm thinking we'll eventually need the modules manager to start with a "categories" selection list, "author" selection list, "what's new", "what's popular" and "installed/updates" options, so you have to choose one of these before you start getting lists of modules. Then once we are listing modules, we've got to have a way of paginating them once it goes past 100 or 200 or something like that. Once we get to that point, we've got something that is sustainable as part of the core. I'm thinking we should target this for 2.4. Edit: will also want to make it skip over any modules that don't match the requirements of the installed PW version (maybe it does this already, not sure). I agree, this is a "core" for me. But the reality is, once modules manager is part of the core, we'll want to potentially reduce the number of modules included with ProcessWire as part of the core. It'll be so simple for people to install modules that it simply won't be necessary for any modules to be part of the core except for the minimum set needed to install and run a blank PW.

Adam, I'm working through one too many modules at once here so haven't had the chance to go through this one yet. I'm sure we'll get it into 2.3, but not positive we'll be able to get it into the first revision or not. But the version he linked above does work, if I understand correctly. So what you might want to do is download that and rename the file and class name in it, to be "MarkupCacheAdam" or something, and then use it as is, since it's ready to go. But good to rename it just so it doesn't get mixed up with the regular MarkupCache once updated.

Finally getting the chance to experiment with the modules manager update, and loving it!

Soma, here's what I did in FormBuilder, which also requires wireRmdir: /** * Temporary, until Form Builder requires PW 2.3 * */ if(!function_exists('wireRmdir')): /** * Remove a directory * * @param string $path * @param bool $recursive If set to true, all files and directories in $path will be recursively removed as well. * @return bool * */ function wireRmdir($path, $recursive = false) { if(!is_dir($path)) return false; if($recursive) { $files = scandir($path); if(is_array($files)) foreach($files as $file) { if($file == '.' || $file == '..') continue; $pathname = "$path/$file"; if(is_dir($pathname)) { wireRmdir($pathname, true); } else { unlink($pathname); } } } return rmdir($path); } endif; Always be very careful with wireRmdir and check everything you send to it to make sure it's correct and not blank, etc. This function always scares me a bit. The wireRmdir function will empty your entire file system if told to.

This line clarified it. Because you can do everything you want using the <img> tag / CSS technique, up until that line quoted above. Though it is a bit of a technicality, so long as your 2nd crop is going to be smaller than the first. In fact, a 400x300 image displayed at 200px width and CSS vertically centered and overflow:hidden at 100px height will technically be higher quality than an image literally at dimensions 200x100. But if you are concerned about file size, then the actual 200x100 image will be more desirable. Personally, I don't have a high DPI screen on my main computer (just my phone), but supporting high DPI now makes us more future proof, as it'll probably be expected everywhere in a couple years from now. So if it were me, I'd go for the CSS technique. But you can get the result you want by taking your 400x300 crop and using the ImageSizer class to make a copy at 200x100: $file1 = '/path/to/your/400x300/file.jpg'; $file2 = dirname($file1) . '/200x100-' . basename($file1); if(!is_file($file2) || filemtime($file2) < filemtime($file1)) { copy($file1, $file2); $sizer = new ImageSizer($file2); $sizer->resize(200, 100); } // file2 is ready to display

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.