ryan

I think the CMSCritic award definitely gave us a big boost. I'd expect it to drop a little in the short term (as it always does after something like that), but the long term trend will continue steadily upwards.

ProcessWire is a native category system, whether by structure or relation. I think the distinction is that we don't call them "categories" or "tags". But "does not have" makes it sound like they aren't part of the plan. When in fact, it's one of the underlying purposes of the system. ProcessWire's grandfather (Dictator CMS) had a category system called "channels" and it took me awhile to realize it, but they were a complete waste of time... The literal channels/categories were immediately rendered useless once the Page reference type entered the scene. I continued using channels on the sites that had started with them, but this antiquated type of category system never felt right again. Today's ProcessWire not only has categories, it has them on steroids. If each business only belongs in one category, and that will always be the case, then categories by structure is a good way to go. Meaning, your structure would be: businesses web-design a1-web ryan-cramer-design accounting acme-financial architecture top-notch-houses dlux-office-design restaurants las-tortillas bread-and-cheese-house If each business can be in multiple categories, then you'd want a structure like this: businesses a1-web ryan-cramer-design acme-financial top-notch-houses dlux-office-design last-tortillas bread-and-cheese-house business-types web-design accounting architecture restaurants Then each "business" page would have a "Page" reference field called "business_type" where the editor can check one or more boxes. Each business would display their types like this: <h2>Types</h2> <ul><? foreach($page->business_types as $t) echo "<li><a href='$t->url'>$t->title</a></li>"; ?></ul> Each business type would display the related business like this: <h2><?=$page->title?> Businesses</h2> <ul><? foreach($pages->find("business_type=$page") as $b) echo "<li><a href='$b->url'>$b->title</a></li>"; ?></ul>

I think that's a definite improvement. If your need allows it, you might want to prevent the inclusion of slashes so that someone can't have it pull in PHP files outside of the directory where you are allowing them. $name = $sanitizer->pageName($name); That will replace anything that's not in this set of characters: "-_.a-z0-9", with hyphens. That adds some reasonable security here.

I took a look at your htaccess, and it appears to me that all the stuff that would matter here has been commented out. So I don't think that's the problem. Can you tell if the links that you click on actually have the full hostname in them? View the source or inspect the link and see if it includes the hostname. Ideally you'd want the link to be like "/path/to/page/" and not "http://domain.com/path/to/page/". ProcessWire itself never uses hostnames in its URLs for this reason, unless you manually put them in or you use the $page->httpUrl rather than $page->url. If you find that's not the problem, I would try it from another browser. Browsers can be pretty stubborn about letting go of hostname related 301s.

They are available for use by other modules. They actually don't have a TinyMCE dependency. The modules don't know they are being used by TinyMCE. They just have a "some/any editor" dependency. You can use them by themselves if you want, but they aren't that useful, as it's the modal dialog buttons (that we coded from the TinyMCE plugin side) that pull the contents of the fields these modules populate, and use them in TinyMCE. I haven't yet used them with any other editors, but have always planned to. If we were to make a CKEditor module for example, we'd use the same two modules to handle images/links.

ProcessWire is a little bit of a different animal than some other CMSs in that it doesn't technically need any [additional] modules in order to do everything one could need. But in the case of profiles, those are something where the reverse works, and someone tracks down a system that does what they need, only to find later that it's built on ProcessWire. Turn-key profiles are definitely one of our paths to growth.

All the issues you mention are the things that scare me about a built-in modules manager, and that have been on my mind for sure. I fully expect to have some new worries. But it's a worthwhile compromise. The modules manager adds a whole lot of value and convenience to ProcessWire. But I think it's going to have to be accompanied by a lot of warnings so that people know the security compromises they are taking when using it. For me personally, I will use it on development sites but not production sites. Though if we have a "trusted" collection of modules that are self hosted (by us), then that could go a long way towards making it more trustable on production servers. As for a global switch, I kind of see that as being the "superuser" role/account. Modules manager should only be accessible to superuser and nobody else. Maybe something more is needed, but I hate to add complexity when trying to add convenience.

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.