ryan

We might have to look further, like what's going on in the template file. But one problem that I can spot in taking a closer look at the code is that the definition of your processRatingInput() method in CommentFormWithRatings.php has no arguments sent to it, but your hook function is assuming arguments[0] is a $page, when in fact it would be null. This doesn't indicate why the hook isn't getting called but it seems like you would get a PHP error in your hook function. I would fix that just in case it is causing the strange behavior or hiding some other error.

It's possible that your index tree needs a refresh. Try dragging the entire /en/ page (tree) below a new parent. Drop it there and let it sit for 5 seconds. Then drag it back to have home as the parent. Now try your query again and see if it's showing up when using has_parent.

When exporting with PHPMyAdmin, I sometimes have to uncheck the "use extended inserts" in order to get it to import somewhere else. Apparently the maximum query length can vary from server to server, and avoiding extended inserts reduces or eliminates that problem (at the expense of a slightly larger SQL file).

This one is fixed in 2.3.2 dev.

If you are still getting that error, I think we need to see the full code for your hook function too (as well as any other code involved in the process). Is the error you are getting specific to the page $p that you are calling $p->save() on? The error you mentioned indicates that something is changing the output formatting state back to on, as it won't throw that error unless you try to save a page that has output formatting on. I am guessing that you need another ->of(false); in your hook function for $brand, but not certain without seeing the full context.

I agree, I think export/import methods like this on Fields and templates would be nice. There's a lot of considerations though, especially on import. Like whether individual fields already exist or not, whether those field definitions reference external things (like page IDs). That's not to say it isn't doable, but just that there is potential for it to get quite a bit more complex than it first appears. But I would like to implement some API level expor/import functions for this soon, to at least get things moving forward. I've already been working on similar export/import functions for Page objects (which you see in the latest dev branch, though they aren't yet active).

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.