ryan

It could be that it simply thinks nothing changed. You might need to give it a hint that something changed. foreach($pages->find("template=brand") as $brand) { $brand->trackChange('num_products'); // add this line $brand->save(); }

I'm all for more validation options, and generally add them as needs come up. But I want to point out that Fieldtypes define a database schema. That's something that differentiates the need for different fieldtypes, is the fact that most represent different storage needs for data. Behind the scenes, they represent a database table. You don't need different fieldtypes purely for validation reasons. Though FieldtypeEmail and FieldtypeURL (and I'm sure others) probably have very similar storage needs... and maybe they could really be the same Fieldtype if we really wanted it that way, but I'd rather have people choosing an "email" or "URL" field rather than a "email/URL" or generic "text" field. This is more consistent with the way HTML5 is going too, as types like "email" and "date" are being used over some validation attribute on text fields. Overall, I think it's easier on the user if they are choosing reasonably well defined types when creating fields, rather than abstracted "I can be anything" types. As for a "unique" validation, that's different from the others. This would best be handled at the Fieldtype level since it's a type of database index that enforces it. I've been planning to add this to the base Fieldtype class, so that it is available for all Fieldtypes. You may have seen the FieldtypeTextUnique, which was more about proof of concept and solving a need quickly, rather than a suggestion of what path should be taken overall. But we'll definitely be adding support for unique indexes in a manner that spans all Fieldtypes rather than just individually. Fieldtypes are involved in the getting and setting of page variables at the API level, making sure that the format is correct for the storage it represents. This is sanitization, just making sure that what gets set to it is valid in general for the type and suitable for storage. But specific interactive validations are the job of Inputfield modules. If there are any major validations we're missing on any of them, let me know and we can get it on the to-do list. I have been working to expand the validation options behind the InputfieldText module, as it now supports regular expressions, which will let you be as specific as you want with validation. New validations have also been added to several other Inputfields over the last year. Configurable error messages at the field-by-field level are something we don't have, but I would also like to see them. This is something I think we can add in the near future. They are currently configurable at the fieldtype-by-fieldtype level, but only if you have the multi-language support modules installed.

This isn't correct, as the CSS selector is specific to focus on the panel you asked about. It's already targeting the settings tab, and the ":first-child" as part of your CSS selector focuses it on the "who can access" field. Without that, it would hide the "info" field as well. But I agree it's better to use Soma's solution as that removes it from the markup entirely.

All of these can be built into the MarkupTwitterFeed module by extending it, or a new module just by copying the relevant parts. If I recall, most of that data comes in the feed it's already pulling, at least if you remove the 'trim_user' option from the $params sent in the request. I added that just because it was sending us way more data than we needed for this module. Twitter's docs are quite good for their API, btw.

The need to have arrays in GET vars honestly doesn't come up very often in my projects. Usually when I'm using arrays, it's with POSTs. But if you want to avoid the array appearance in your URLs, you could always solve it by intercepting the request and reconstructing it to have your desired style, i.e. if(!empty($input->get->array_var)) { $csv = ''; foreach($input->get->array_var as $value) $csv .= ((int) $value) . ","; $session->redirect("./?csv_var=$csv"); } Is it worth the overhead? Probably not, and all GET variables are ugly to some extent. But just showing it's possible to do without going the javascript route.

This is a great feature, thanks for adding it Pete!

This should probably be posted in the CropImage / Thumbnails thread, as I'm not sure the authors of the module will see it here. Either that, or it may be good to submit an issue report in the GitHub repo.

Thanks for the followup and details on how this is going SteveB. Glad to hear it's going well and sounds like you are having fun with it too. You mentioned using a template engine–which are you using, or are you using the TemplateFile class? Glad to hear you like (or will like) the new conditional autoload features. I think that passing your own variables through the $page object is a fine way to go. But wanted to mention that the $page->render() method now accepts an array of variables you want to pass to the template file that gets called, and it can be accessed in the template file via the name $options. Not sure if this is useful in your case or not, but wanted to mention it.

Sounds to me like you might have max width/height settings defined in your images field (Setup > Fields > [your image field] > Input). If that's not the case, then what you are seeing is just client-side scaling in your browser. And there shouldn't be any cropping. The image is full resolution, but just being scaled to 100% of the container width. That doesn't mean the image is actually that size. That just means that it's presenting it to you in a manner so that you can see the full contents of it. When inserting into your rich text field, do so by clicking the image button in the toolbar, rather than by dragging the image into there. The act of dragging may cause your browser to insert its own width/height tags as part of the clipboard data.

This is good to hear. While I've not used Laravel, I honestly thought it was a completely different animal in terms of a framework. That being that ProcessWire is a content management framework/system and Laravel is an application framework. But to hear that there is enough crossover that you can accomplish similar things sounds good. Perhaps we should put more focus towards appealing to framework users. I agree with you that once we have Composer support, that will open up a lot of new possibilities.

Try posting this to the ModulesManager thread so that Soma sees it. But I ran into a similar issue at one point after migrating a site. You may have to go back and check that your /site/assets/cache/ is writable, and perhaps manually remove an existing cache file if it exists.

If you want to use the LanguageSupportPageNames module, I think it's better to go ahead and use the dev branch (if you are in a site development phase), just because (like Soma mentioned) the development for it is a lot further along there.

Some fun stuff just pushed to the dev branch: the core now includes a Modules Manager "Lite". The screenshots below best describe how it works. But it lets you install modules from the directory just by typing (or pasting) in the module's class name. It also provides a 1-click capability to check for a given module's updates and upgrade it when necessary. Beyond that, the modules screen is now split into tabs: Site, Core and New. Site shows just your /site/modules/, and Core shows just your /wire/modules/. The New tab is where you can install modules. I really wanted a solution that kept the actual browsing for modules out of the CMS. Not because I think it's a bad idea (it's a great idea) but because I wanted the modules directory (modules.processwire.com) to serve that purpose as much as possible, at least as a default. That way I don't have to worry about scalability as the size of the modules directory increases. Plus less automation might make the newbies be a little more careful about what they are installing and where it's coming from. The power of the automation in ModulesManager here is so powerful it scares me, so think it's better for the users that know what they are doing. Lastly, ModulesManager is one of the best modules out there and Soma does an amazing job with it. Bringing a little taste of ModulesManager into the core I thought would help both projects. Most credit for the new core "Modules Manager Lite" goes to Soma (though he doesn't yet know that). It's all built around his code lifted directly from Modules Manager. Hope that's okay Soma? Your code now powers not just the new stuff in ProcessModule, but also the new WireHttp::download function, and the new wireUnzipFile() function, all added this week. People who want the most power will still want to use Soma's Modules Manager. That does a whole lot more than the built-in one does, including installation of themes, checking for updates en-masse, and browsing and filtering through the modules directory. But now you can install ModulesManager or other modules without having to manually FTP things to your server (so long as your /site/modules/ is writable). Please let me know if you guys run into any issues with it.

Okay just tested with AdminBar, and man it is nice to see it again. Everything works for me. I think I'm going to keep it here. You might want to check your site to see if you've got any JS errors or anything like that. If I understand how AdminBar works correctly, it could be interrupted if you had something else on your page triggering a JS error, or didn't have jQuery or something (possibly jQuery version?)

AdminBar is great I agree. But I'm so set in my old ways that I still always just place my own edit button in the top left corner, and nothing else. So I haven't yet had the opportunity to test AdminBar with 2.3.1. I'll install AdminBar and see if I can figure out what the issue might be.

Actually autocomplete fields have never worked in tabs before... they always had to be on the primary/first tab in order to work. But a week or so ago, someone submitted an update that lets them work in tabs, so I went ahead and committed it to dev. It works here at least. If you are running the latest dev, you might just want to check that you don't have an old JS file cached or something (hit reload a couple times on the page). Here is the commit where it was added: https://github.com/ryancramerdesign/ProcessWire/commit/9a3bf9caa47f204e938213c8ff5cd31691a7c245 If the issue persists, please let me know what browser.

This is a little bit of a tough one because dates are basically sortable integers. So a 0 is considered end of 1969 (or somewhere around there). You can query for those with a 0 date value and those with a date>$now with separate children() calls. But when it comes to pagination, the question becomes how you would want to sort those with no date value and those with a date value. If one or the other can be consistent at the front or back, that will make pagination simpler. Also you can manually set the pagination limits on a PageArray with $all->setLimit(); $all->setTotal(); etc. Another option is that you could always query the database manually to find the IDs of the matching pages, then bundle that into your children() query. Here's two example, one using PDO (PW 2.3.1 and newer) and one using mysql (PW 2.3.0 and earlier): // using PDO $now = date('Y-m-d H:i:s'); $sql = 'SELECT pages_id FROM field_expiration_date WHERE (data IS NULL OR data=0 OR data>:now)'; $query = $database->prepare($sql); $query->bindValue(':now', $now); $query->execute(); $ids = $query->fetchAll(PDO::FETCH_COLUMN, 0); $expired = $page->children("limit=20, date<=$now, id=" . implode('|', $ids)); // using mysqli $now = date('Y-m-d H:i:s'); $sql = "SELECT pages_id FROM field_expiration_date WHERE (data IS NULL OR data=0 OR data>'$now')"; $result = $db->query($sql); $ids = array(); while($row = $result->fetch_row()) $ids[] = list($row); $expired = $page->children("limit=20, date<=$now, id=" . implode('|', $ids));

I'm not sure we can answer this without seeing the bigger picture here. But since your code is iterating through a property of $page, and not referencing other variables you had like $child or $result, chances are you can put this wherever you want. It looks to me like it should be outside of any other loops. I would just put it where you need it.

Technically repeaters can be nested (I've done it before, though disabled it), but it creates so much potential for problems that I didn't think we'd want to support that. Plus considerations for 3rd party Inputfield modules, and the list goes on. The situations where nested repeaters are worth the compromises is pretty rare, as there's usually a better way to accomplish the same thing. Ultimately decided we shouldn't have support for it at this time. But if you can describe what you are trying to accomplish with nested repeaters, I may be able to describe alternative ways to achieve the same thing.

Great form builder implementation you've got here too. I love the way you styled it and the way you've setup JS-based field dependencies. Awesome work.

Shopify is another decent payment solution to integrate with ProcessWire. Shopify is pretty much self running and easy to setup (they host it), but has a feature called post order hooks that you can have ping your defined URLs (in your PW installation) with JSON data about a completed order, etc. This makes it fairly simple to create or modify user accounts or other pages based on the results of a store transaction.

I don't see anything wrong with #2, other than that I'm wondering if your $pages->get($local_lang_url); really makes more sense to be a $page->rootParent call instead? But if your current one isn't working, I would suggest that the /de/ page does not have any visible or viewable children that have a field 'page_key' with the value 'block_m-help-legal'. Are you sure you didn't intend for your children() to instead be a find()? Example: $blocks = $page->rootParent->find("page_key=block_m-help-legal"); The problem with #3 is that it looks like you are expecting a PageArray, but getting a Page. If you simply changed your get() to a find(), I believe it would do what you are expecting. And it should return the same exact results as the example above I posted. If you can achieve the same thing with one find() that you could with a combined get() and find(), then the single find() will likely be faster. For all practical purposes, it probably doesn't matter much though. If your level-1 pages are language segments, like "/de/" as you mentioned, then $page->rootParent will always refer to the root of your current language. I have a feeling this is what you want to be using rather than detecting it some other way. find() is not slow. Every function that returns a Page or PageArray eventually gets routed through find(), so we've really tried to make sure it is fast and optimized. But I still think you probably want a $page->rootParent->find("page_key=..."); rather than a $pages->find("has_parent=...");

Thanks for the update–It works perfectly here! I will submit a pull request to you that makes the title attribute translatable. I also moved the hook-attach logic to a ready() method (rather than init), and made it attach the hooks only if the page template is 'admin'.

I totally agree that we should strive to keep clients away from code when we can. But things like phone numbers and email addresses aren't far off from the type of codes we're talking about here. Sometimes a bit of code (more a tag in this case) that references something is the simplest possible solution from a development standpoint. In this particular case, the tag could technically be completely behind the scenes and the client could just see an image. That would be ideal, and I think this is what we should strive for long term. But the implementation of that is no doubt expensive (time and money) and has editor dependencies. The solution that works for TinyMCE 3 won't work in CKEditor or even TinyMCE 4. I don't think anyone disagrees on what would be the perfect solution from the user standpoint, and this is what we should eventually aim for… when someone can afford the time/cost investment to make it happen. But I also like to see solutions that solve problems, that are maintainable and realistic with time and budget. They provide solutions to questions that would otherwise remain unsolved, sooner rather than later. Very often these are also important intermediate steps that eventually facilitate creation of something even better.

Currently I can't see any reason why this wouldn't work. But a few things you might try: 1. Clear your opcode (APC?) cache. I do this whenever I encounter something odd that doesn't add up. 2. Clear your modules cache. You can do this by clicking "check for new modules" on the Modules tab. 3. Check your Comments field settings. Is it set to redirect after post? Try disabling that option, temporarily, to see if it makes any difference. 4. While I'm not aware of any issues related to this in PW 2.3.0, maybe try switching to the dev branch (2.3.1) just to change things up. Also: Uninstall your module. Then click "check for new modules", then re-install it. I'm wondering if it maybe started out as NOT autoload, and that setting got cached in the DB. PW doesn't load all the module settings at runtime, as it caches some of them, especially autoload status.