ryan

Thanks, I think I've got this fixed. Try out the latest dev commit. Your best bet is to use no language segment for your default language. So when you edit your homepage, on the "settings" tab, make sure the default language field is blank rather than "en".

I'm really liking CKEditor in usage, but admittedly don't know how to do a lot when it comes to extending it yet. But if you guys figure out how to do this, let me know what config options I can add to the module and I'll be glad to.

I like what you are saying about the dependent validations, and something that validates a whole page sounds interesting. Though since fieldtypes and inputfields are of types that may be completely unknown to the page (since they are plugins), and independent from one another, the core has to keep the validation connected with the fields. But as an external validation option I think it sounds interesting.

This is something I'm adding.

Makes sense to me. The only thing is that PW core doesn't come with an Inputfield that does this, so it would be an external 3rd party dependency... something I'd like to avoid. So what I'll probably do is make the Inputfield type configurable so that you could tell it to use some future code-editing Inputfield instead of InputfieldTextarea.

The modules directory has been updated so that it talks a lot more with GitHub behind-the-scenes. This provides the following new features for modules that are hosted at GitHub (which is the majority): It keeps your module version up-to-date automatically. You no longer need to go in and edit your module listing to bump the version number. It performs this check on every GitHub repo linked by the directory, once per day. So once you update the version number in your module's PHP file (getModuleInfo), and have it committed to GitHub, that's all you have to do, as the directory will detect the change in a few hours. When you add a new module, it is able to pull in most of your module's information automatically from GitHub after you specify the project URL. As a result, the add new module link asks for your project URL before anything else. The directory now displays the contents of your README file at GitHub, and keeps it up-to-date automatically (checking it once per day). Because of this, you may no longer find it necessary to use the directory's built-in Extended Description or Instructions fields. I recommend that you have your README in either Markdown (README.md) or Textile (README.textile) format, which just looks better, but plain text is of course supported too. Hopefully this makes it a whole lot easier to keep your modules up-to-date in the directory. Please let me know if you run into any issues with it. Please note: Your module must have the same name as the repository. Meaning, if your repo is named MarkupTwitterFeed then your module must be named MarkupTwitterFeed.module. This appears to already be the case with all the modules in the directory, so I'm not sure this even needs to be called out, but figured it was worth mentioning just to be sure.

Pagination is now fixed on the dev branch. Also you can now translate the the prefix segment (i.e. "page[n]") used for pagination in URLs. By default it is "page" for "page2", "page3", etc. But if you want to translate that on a per-language basis, you now can in the LanguageSupportPageNames module configuration screen. For instance, in Spanish you might want to make it "pagina" for "/path/to/page/pagina2", "/path/to/page/pagina3", etc.

I think that these guys posted the best solutions for what you are trying to do, since they cause the operation to take place before page is actually loaded. But if you do have a need for a comparison function such as that, you can use $page->is("selector") or $page->matches("selector"); which are similar to what you were looking for with a has() method. When used with a selector, both of the functions do the same thing. The only difference with is() is that you can also send it a template name, like $page->is("product"); or a status like $page->is(Page::statusHidden). Both functions return a boolean true or false.

What's confusing to me that you say it outputs content without html or body tags. That seems to indicate that something, somewhere is stripping them out? Seems pretty unusual. It sounds to me like whatever output buffering and markup replacement that SF might be doing needs to be turned off?

Thanks for the report. I can confirm the issue and was able to duplicate it here. I should have it fixed later today on the dev branch and will try to remember to post back here once I do.

Updated version to 2.0.1 which adds a 'relative' option for the date/time stamp setting. That makes it display the time as strings like "5 minutes ago", etc. The other change is that the module can now be iterated with a foreach(), useful for people that want to handle all of their own markup generation. If you take this approach, be sure to read the example and notes in the readme file.

Have you tried out Soma's ImagesManager? This might be a good solution for you, or a starting point to extend.

If it was working before, it sounds like some change occurred at the server where the file permissions got wiped out and the PHP version changed (to one with GD?).

You can include_once() or require_once() the library's autoloader or bootstrap file directly from your ProcessWire template file. You can basically treat ProcessWire template files as plain PHP files and use it in the same manner. If the library is something you are wanting to include on all template files automatically, you might want to include it from an init.php file per the $config->prependTemplateFile option available in /site/config.php. ProcessWire uses blowfish hashing for password security of users in the system, which is the recommended approach.

In order to do that, the "pwimage" plugin needs to come out of the TinyMCE plugins list. Since this one is hard-coded in the InputfieldTinyMCE.js file, you might need to edit that directly. You'd want to remove the reference to "pwimage" in the two spots where it appears: var InputfieldTinyMCEPlugins = ['pwimage', 'pwlink', 'advimagescale', 'preelementfix']; ... tinyMCE.settings.plugins += ', -pwimage, -pwlink, -advimagescale, -preelementfix' + custom_plugins;

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.