ryan

Beautiful. Chrome is quite the artist.

It should be fine to use $config so long as you aren't overwriting some property already in use. Though you might also look at using $page to store your runtime/temporary properties, as $page is more associated as a runtime variable.

Thanks for the report Doolak. I see the issue report at GitHub too. I think I know what the problem might be and will test here.

That means most likely a javascript error is occurring somewhere on that page. If you open your javascript console, do you see any error messages?

Personally, I prefer not to use the long version tags because it's just more verbose and hard to read. I only use them if I'm developing something that has got to be portable to systems I don't know of. That's why you see me using the long version tags in PW's code and profiles. But if I'm developing something for a client or myself, where I have some control over the server, I stick to the short echo tags when possible. I was very happy when I heard the PHP 5.4 announcement was making the short echo tag standard (that's the main one I care about).

Sounds great Nik, thanks for this info. I think this is a great platform for the test framework. What do you think are the next steps to take? Let me know what I can do to contribute -- maybe assign a task to me?

This thread is probably the closest. But the blog profile is nothing more than common PHP and ProcessWire API usage, so pretty much everything PHP or ProcessWire related in terms of documentation will be relevant. The ProcessWire API cheatsheet is one of the best resources as well.

Matthew, that would still work. But the strtotime calls you have there are unnecessary. If you need to wrap those components in spans, using $page->getUnformatted() might be more efficient than strtotime: <div id="news_date_box"> <span class="month"><?php echo date("M", $page->getUnformatted('created_date')); ?></span> <span class="day"><?php echo date("d", $page->getUnformatted('created_date')); ?></span> <span class="year"><?php echo date("Y", $page->getUnformatted('created_date')); ?></span> </div> or: <div id="news_date_box"> <?php $date = $page->getUnformatted('created_date'); ?> <span class="month"><?=date("M", $date)?></span> <span class="day"><?=date("d", $date)?></span> <span class="year"><?=date("Y", $date)?></span> </div>

Thanks er314, I'll do some testing here and see if I can duplicate it (and fix it if so). If not, I might need to get more details on how to reproduce, but I think I've got enough to go on for now.

Nice job Khan! Perhaps we should integrate this as an option into the main Comments fieldtype? Or should be be a separate fieldtype (under a different name)?

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> ";