ryan

All fieldtypes provide their own validation configuration options. Some have a lot of ways you can customize and configure the validation, whereas others don't. Which fields do you think would benefit from more validation options, and which validation options would you add? I regularly add more configurable validation options to fieldtypes, so always looking to spot needs here. Can you go into more detail -- I'm not sure I understand? At least the code igniter example is confusing to me because it seems like it is just wrapper functions for general purpose form markup, and not clear on the benefits of that. But I'm also confused about the creating/editing pages part.

Good idea. I've added a role exclusion feature to the module's configuration so you can check boxes next to any roles you want excluded from sending notifications. https://github.com/ryancramerdesign/LoginNotifier/commit/178c45681deab344e120eb64e4270a23866626e8

We can open this up so it doesn't filter out brackets. But it would only be in 2.3+, so this module should probably stick with the current method for the moment.

Good to see you here Radik, and thanks for your work with the localization and module. This is a high volume function, so I'm implementing the hook a little differently here. Can you try replacing your LanguageSupport.php file with the attached and let me know if this still works with the hook the way you need it? LanguageTranslator.php Also, when ready, it would be great if you'd like to add your localization and module to the modules directory at: http://modules.processwire.com/add/

If nothing is going to get stretched to reach the target, and the source is bigger than the target, it's kind of splitting hairs. My eyes won't be able to tell the difference at least (not that I have good eyes). I don't disagree that the capability is desirable and that there will be those cases where one would have better than the other. But everything costs time and money to do, and so the developer of this module (or the developer of any module) often has to focus on their own needs. If it's not something the developer will use themselves, it can be too costly to develop without a sponsor or collaborator. If this is something you believe in and are interested in developing, you can always update the module and submit a pull request, or offer to sponsor the feature with the developer. Sooner or later someone will have a similar need, so it's also good to get the ideas down here as you have, as another developer may come along and implement it too.

Antti has been developing a Shop module for ProcessWire and it is in successful use already. I'm not sure how many other users might be using it, but I think he's done a very nice job with this. However we don't have plans for e-commerce to be part of ProcessWire's core product, at least not in the current roadmap. So any e-commerce solutions for ProcessWire will be 3rd party solutions, whether running on ProcessWire or on an external service. I've developed and run an online store for many years and have quite a bit of experience with several self-hosted e-commerce software products, and more recently, hosted e-commerce products. When a client asks me what to do for e-commerce, I like to point them towards services like Shopify (my favorite), Volusion, BigCommerce, etc. These services are targeted specifically towards the needs of e-commerce in a way that no self hosted product can touch (at least for what matters to me and my clients). Plus they are hookable (at least Shopify is) making it easy to perform actions in your PW site based on an order, in real time. Paid membership sites suddenly become a piece of cake. This makes nearly anything possible, and IMO more powerful even than dedicated products like Magento. Now with PCI compliance (at least in the US) I really dislike the hassle and time expense of self hosted solutions for my own needs. I don't think ProcessWire needs to be all things to all people, and I'd rather focus our energy on the things where we are and can be better than everyone else. For the same reason, I don't want us to invest time in creating forum software when something like IP.Board exists. We want to empower web developers with the best solutions out there. This is a much bigger question for proprietary and non-open source products. It's a good question, but doesn't have the same gravity when applied towards an open source product with hundreds (or thousands) of people around the world familiar with the system and code. At least in our case, when a bug turns up, many times the user submits a fix with the bug. Beyond these forums, I also do some support email. But very little comes to me anymore. The forums and community here have been better than I could have ever imagined. I should also note that a goal for 2013 is to provide commercial support options for those that want it. I'm not yet certain if the market is there for it, but it's something I would like to have available. We are on a path for growth and I see us continuing our current strategy of building and improving the software and resources around it. My 5-year goal has been for us to power 3% of the PHP open source CMS-driven sites in the world and/or be top 10 (open source) in terms of usage. I think that our growth comes from WordPress users looking for more, and front-end developers getting into content management without a previous allegiance. We'll also get our users from other CMSs. But WordPress is the one building the audience, and the developer and non-blog-portion of that audience is using the wrong software. With that audience, ProcessWire answers everything that WordPress can't, while being simpler to use and develop for. There are other CMSs that are also good stepping stones, but all are significantly more complex.

This is one of those settings that most people probably won't take advantage of (and may not need), but the people that might benefit from it will really appreciate it. When settings like this are hidden in PHP code, it's a lot less likely people will ever know about them. You have to track down documentation to know that the setting even exists. Whereas, if it's a configuration field that's always visible with the module, it's a lot less likely to be missed. This is why most settings like this are done through the admin UI. Though admittedly, this is one case where I think it'd be perfectly fine for it to be in the static $config too (since 80% of people don't need it). I also wonder if it shouldn't just be defined when the cache is created, with a $cache->expireWhen(...); or something like it, before a $cache->save(). Ultimately there may be no right answer for every case, but the current UI module config seems like a good common denominator.

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