ryan

What is the problem you are seeing with find() ?

You can't currently pass things back through $options, so $page would definitely be the way way to go there. I actually take the same approach as you, passing things through $page. That's in part because most of the times I've done it were before $options was around, but also because it's simple, unambiguous and easy to remember how it works. I'm not sure I understand all the details of the scenario you are talking about. But if you've got several PageArrays in memory and you want to determine which one contains a given page, I would think you'd just add a loop to the mix? $pageArrays = array($somePageArray1, $somePageArray2, $somePageArray3); foreach($pageArrays as $pa) { if($pa->has($somePage)) { // you found it } }

The case study that was in this thread (and following posts) have been moved to: http://processwire.com/talk/topic/3987-cmscritic-development-case-study/

A string or something like FieldtypeText probably isn't the best example to consider when talking about overall Fieldtype design. The Fieldtype architecture is built around being able to support complex data types that might translate to a DB schema with numerous fields within the table. FieldtypeText is the absolute simplest case scenario for a Fieldtype. With the HTML5 example, I'm only talking about definition. I want people to be able to define their fields in a manner that bears some consistency with how they might define their fields in HTML5. Having an 'anything goes' text field that we later check boxes for what we want just doesn't fit the way I'd like users to define fields. I think that's fine for specific details like "max length" or the like, but not for something defining a type like Email or URL. Such an approach would mean we'd likely need to have yet another level of plugins below type, for type validation. This method would be supported by the current architecture if someone wanted to take the approach (it's not far off from how Textformatter plugins work), but I think it would ultimately be a less desirable approach for the core fields. It's important to consider that ProcessWire has two different input levels that have distinct needs: interactive and API. Inputfields aren't involved with API-level usage of ProcessWire, only interactive usage. API-level usage of ProcessWire is another type of input being provided to the system, but one that is certainly different than interactive. This level is more about protecting the type and preventing corruption. As a result, Fieldtypes typically sanitize and Inputfields validate. But if your Fieldtype benefits from some kind of API-level validation, you always have that option. The architecture of Fieldtypes and Inputfields has a whole lot more to do with being scalable to complex data types and needs, and flexible enough to handle diverse situations. For instance, if you wanted to have a FieldtypeAnyText with separate validators, it would be easy to implement under the current architecture. Luckily this is exactly what a MySQL unique index does. It would have to be a Fieldtype-level setting rather than an Inputfield-level setting, since the Fieldtype controls the schema.

I think he's talking about the page name field on the settings tab. It says "Active" after each language name, like "English Active", "Spanish Active", etc. It looks like it's picking up the LanguageSupportPageNames checkbox label in the tab. As far as I can tell, WillyC's solution above was to prevent it from making tabs out of the page name field. Tested here and seems to work.

There was a request that I add an official thread for this module, so here it is. MarkupTwitterFeed generates a feed of your tweets that you can output on your site. When you view the processwire.com homepage and see the latest tweets in the footer, this module is where they are coming from. This module was recently updated to support Twitter's new API which requires oAuth authentication. modules.processwire.com page GitHub project page Usage instructions

The only InnoDB table I'm aware of in ProcessWire comes from the DB session storage module, which is able to perform better with InnoDB than MyISAM. ProcessWire uses ascii_general_ci in some cases where the field can only ever support characters from the ASCII set, like "name" fields for instance. Everything else in ProcessWire uses utf8_general_ci. If you are seeing latin1_swedish_ci, chances are it came from an old version of ProcessWire or from a module that didn't specify collation. In some cases it matters, in others not. You may even want to change the collation in order to affect the way it sorts, for example. Ultimately I don't think you need to worry about it unless you have something that doesn't work properly or you want to change away from the default behavior of something. The defaults that we've chosen are what you want at least 99% of the time.

It is, though I figured most would use the "check for updates" link in the module settings. But it uses the same function as the install, just for DRY reasons. Felt weird? Maybe be a little more gentle... lightly tap, don't hit. Good idea, I'll add a $this->message("update is available"); or something along those lines. Also a good idea, I'll add it this morning if possible.

The info field (in the page editor settings tab) is currently specific to server time and not affected by timezone settings.

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.