ryan

How are you doing this? With a style attribute or actual "width" and "align" attributes? If you are using non-style attributes, it could simply be a matter of them being deprecated in HTML5/XHTML? Double check that you are using a style attribute. I honestly don't know off-hand which ones are deprecated or if TinyMCE even cares, but using the style attribute, or better yet, a dedicated class name is probably the proper way to do this stuff. See if you can find a consistently repeatable condition that we can test.

It's static so that all configurable modules can share a common interface. Some modules do stuff when they are instantiated, like hook things, queue CSS or JS files, or other things that aren't related to configuring a module (and may even be a problem if present when configuring a module). So we need the ability to know what it takes to configure a module without actually instantiating it. The only module type that would be instantiated at the same time as configuration would be an autoload module. If you are dealing with an autoload module, or you are willing to manage your own configurable vs. executable state, then there is an easy pattern you can follow. This assumes you have two configuration variables in your class, 'foo' and 'bar'. class MyFooBar implements Module, ConfigurableModule { public static function getModuleInfo() { /* you know what's here */ } public function __construct() { // set your default values for config variables $this->set('foo', ''); $this->set('bar', 0); } public function init() { // note that PW populates the actual values for your config vars, 'foo' and 'bar' // before this init() function is called, but after __construct is called. That's why // we set the defaults in __construct. Once you get to this init(), your config is // now populated, and likewise available for this non-static function below: } public function getConfig() { // you can name this function whatever you want, since it's not part of any interface // this is the stuff you would usually have in your static getModuleConfigInputfields // see how we can pull the values from $this->foo rather than $data['foo']; $inputfields = new InputfieldWrapper(); $f = $this->modules->get('InputfieldText'); $f->attr('name', 'foo'); $f->attr('value', $this->foo); $f->label = 'Foo'; $inputfields->add($f); $f = $this->modules->get('InputfieldInteger'); $f->attr('name', 'bar'); $f->attr('value', $this->bar); $f->label = 'Bar'; $inputfields->add($f); return $inputfields; } public static function getModuleConfigInputfields(array $data) { // note we don't actually need $data in this pattern $module = wire('modules')->get('MyFooBar'); return $module->getConfig(); } }

$event = $pages->get("template=calendar-event, sort=calendar_event, calendar_event>today"); if($event->id) { // you got one } That's repeating what nik already said. But I wanted to mention that you can just type "today" in the selector (no need for the mktime). PW runs any non-integer you put in there through PHP's strtotime(), so you can do things like "today", "yesterday", "next week", "+3 hours" etc.

Thanks Steve, good idea! I have merged your pull request.

Making the labels configurable based on field values within them, as well as making them initially collapsed, have been mentioned a couple times. Given that, I think we'll have to add this the next time updates are made to the repeater Fieldtype. Repeaters aren't meant to scale infinitely, so if you need that kind of scalability repeaters aren't the best way to go. Though, you'll be glad to know we also plan to introduce pagination to repeaters eventually... so they will be more scalable from the admin interface side.

The Datetime fieldtype no longer relies upon strtotime, as it takes your desired input format and then translates it. So whether 1/2/2013 means January 2 or February 1 to you, ProcessWire will take the lead from your input format, rather than how strtotime would translate it. On the other hand, if you are working directly in PHP with strtotime, then you do have to keep track of how it interprets the different formats. If you go with day/month/year, then you need to use hyphens rather than slashes. If you go with month/day/year then you need to use slashes.

The blog profile is meant to be roughly equivalent to what you get with a default WordPress install, but of course there are all kinds of possibilities with how it could be taken further. But the intention really is to keep it as a useful starting point, though I'd be happy to see new profiles built that extend it.

Nice work dynweb, thanks for posting this! Please add to the modules directory when you are ready too. One question I have is about the resizeThumb function. This may have come from one of the other modules you mentioned, I'm not sure. But it looks like it creates images in a different file format than the ones ProcessWire does, so I'm wondering what happens to those images when their source (larger) image gets deleted? Do the thumbs continue to exist? If so, you might want to change this to follow the same format of PW's images, which is [basename].[width]x[height].[ext]. If one of width or height are not defined in the resize, then they can be zero "0". But if your thumbnails follow this format, then ProcessWire will take care of cleaning them up when the source image is deleted or replaced.

Thanks Radek, I have added these is the latest commit to dev.

Thanks for the report Nikola. I've tried this a few times and so far I can't duplicate it. Are there any other factors you can think of?

Also see this post, which shows you how to create a 'switch' function, similar to what you may see in EE.

It's hard to say exactly here because I don't see where the <div class="row"> is output in the code example. But generally if you want to take some action (like outputting an opening or closing div tag) after a predefined quantity of items, then you'd use the PHP modulus operator, as described above in an earlier post. Or you can use a counter variable ($cnt) that you increment on every iteration and then check if it's at the iteration you want. For example, this would have two span6 divs within each row div: $cnt = 0; foreach($something as $item) { $cnt++; if($cnt == 1) echo "<div class='row'>"; // start new row echo "<div class='span6'>Content</div>"; if($cnt == 2) { // end row echo "</div>"; $cnt = 0; // reset } } // if $cnt != 0 then we have an unclosed row, so close it: if($cnt) echo "</div>"; It's possible that the last row div could have only one span6 div. If you wanted to prevent that possibility, you'd add this before the last line: if($cnt == 1) echo "<div class='span6'>Content</div>";

The best way to check if the language is default is: $user->language->isDefault(); …but if you prefer to add your own fields to the Language template (like 'code') then that's fine too. Another alternative is that you could add your own defines to a common include, and then compare against them. define("EN", 123); // ID of english language page define("ES", 456); // ID of Spanish language page define("FR", 789); // ID of French language page Then whenever you want to compare a user's language, you could do something like this: if($user->language == FR) { // user's language is french } We will be adding more multi-language fieldtypes as time goes on. Thus far there hasn't been a lot of demand for more than the ones we've already got, but it's always been the plan to keep adding more.

Assuming this is also easiest for you, GitHub issues are great. I prefer this because: 1) I can reply to the emails it sends me and it goes in the thread; 2) I can reference the issue # from a commit and it goes in the thread; 3) It notifies you when I fix it; 4) It's impossible to miss or get lost--it stays there till I fix it. Whereas, in the forum it is easy for me to miss or lose things just because there is so much here. I need to learn how to use PHPUnit so that I can help with this. I looked through the code, but am not yet grasping how it works. I'm not totally clear what PHPUnit does that couldn't be done with a couple small functions of our own, but I hope to be over my ignorance on that soon. I will read/study more here and get up to speed so I can participate.

You can't do this from the admin, as user management there is intended as an administrative task. But you can use the API to check and enforce role settings specific to your needs. For example, here's how you might make a "create vendor" form: if(!$user->hasRole('editor')) throw new WireException("You don't have access to add users"); if($input->post->submit_add_user) { $name = $sanitizer->pageName($input->post->user); $pass = $input->post->password; if(empty($name) || empty($pass)) { echo "<h3>Name and password are required</h3>"; } else if($users->get("$name")->id) { echo "<h3>That username is already taken</h3>"; } else { $u = $users->add($name); if(!$u->id) throw new WireException("error adding user"); $u->pass = $pass; $u->addRole('vendor'); $u->save(); echo "<h3>Added vendor: $u->name</h3>"; } } echo " <form action="./" method="post"> <h2>Create new user with vendor role</h2> <input type='text' name='user' /> <input type='password' name='pass' /> <input type='submit' name='submit_add_user' /> </form> ";

Well I think in this case, it's just that PHP doesn't have a built-in translation engine for this stuff. Functions like strtotime() do recognize English month names and such, but I think they are really intended to translate the most commonly used date strings to unix timestamps (most of which are digit based). It would be like it was/is in 2.2.9, as I think English is the default. Maybe I can just put in a note there, along the lines of "Warning: in languages other than English, stick to digit-based date inputs as only English month names are recognized in string-to-time date conversions." … or something like that

Not a poke at all. Right now I'm focused on getting 2.3 out and some client work, so not yet at a point where I can get into development for this. But these are all good ideas that we'll get into soon. I enjoy reading this stuff and then letting it marinate on the mind for awhile. Keep the conversation going. Once I get to a place where development is near, my posts will make yours look like short posts.

When you are manipulating a page for the purpose of saving your changes via the API, then you want to make sure that the output formatting state is OFF. When output formatting is OFF then your images field will always behave as an array. The single-image reference (with setting 1) is primarily for front-end syntactic convenience so that you can do echo $page->image->url rather than $page->image->first()->url. But behind the scenes, it's still always an array. This reveals itself when you try to set a value to it and output formatting is on, for instance. But in general, it's not good to set any values you intend to save when output formatting is on.

Btw, for anyone else trying to install Pear/PHPUnit on the latest MAMP (and possibly other recent versions), Nik's install instructions don't seem to work, at least they didn't for me. I think it's because MAMP has it's own [already installed] copy of Pear separate from OS X's copy. The very last entry on this page at Stack Exchange worked for me. It's the one answered Oct 9 '12 by Allen Hurff. Failed asserting that actual size "two words" matches expected size "one word".

Thanks Nik, this is fantastic! I'm already using and benefitting from it here. Just fixed two PW bugs, as you posted on the GitHub issues report. It's so nice to be able to run this to locate bugs and inconsistencies, and even better to run again after fixing them (to make sure some new problem wasn't introduced). Thanks again for your great work on this.

Take a look at this old thread too--might be similar to what you are trying to do: http://processwire.com/talk/topic/28-having-multiple-databases-hacking-pw2-to-work-on-two-different-servers/

It doesn't look to me like you are sending your query (q variable) through the ajax request? I'm guessing the code above would just retrieve the URL /busqueda/ with no query.

I agree it would be nice, but I don't see a simple solution to this one. The code that's tracking the changes doesn't know anything about multi language fields.

What do you think--better to leave out the jQuery UI datepicker translations to avoid this issue, or is it worth the compromise?

We do need to setup something like this, and hopefully will soon.