ryan

The tooltip() function is a recent addition to jQuery UI. The dev branch is using the new jQuery UI, while 2.2.9 isn't.

Could cause problems with modules that are loading other modules or populating JS/CSS files to $config->styles or $config->scripts. If your module is already an 'autoload' module, then it should be no problem since it's already loaded and obviously not a problem. But this is more of a consideration with Process, Inputfield and Jquery modules, that are loaded on-demand, as they do trigger loading of other assets. And you don't want those assets loaded unless the context is right for them to be loaded. Ultimately it just depends on what your module is doing. Since PW doesn't know what all the modules are doing, we needed a universally safe way to configure all modules, and a static method gives us that. But that doesn't mean that you have to stay static when you don't need to.

Not sure why the follow-up message wouldn't be shown. Was the comment still saved?

Thanks for testing. I don't have IIS to test with, so will just wait to see if this particular issue pops up for anyone else, before we try to debug it.

Joss, please add to the modules directory when you get the chance.

Sounds good, I'll get both files updated.

I was able to duplicate it here with the blank profile, but not other profiles. I tracked it down to the lack of a /site/install/files/ directory. It looks like the installer needs there to be a files directory present for some reason (something I think I can fix). And of course, this being a blank profile, it has no files. But to get this profile working today, all you need to do is make sure you have a 'files' dir in /site/install/. There doesn't have to be anything in it.

Nice work Joss! Tried it on my phone first, then on my desktop--works and looks great on both.

Doolak, I will go ahead and make this translatable and included in the core this week -- didn't realize I'd missed this one.

Thanks Radek, this has been updated.

I could be wrong, but I don't think that the Redirects module works with source URLs that have query strings or anchors. I think you'd probably have to handle these redirects from your .htaccess file. The /#/pagename/ style URL is an unusual URL mapping system. It looks like it's trying to hack around using homepage anchor links to deliver different pages. Usually anchors would be to jump to different parts of the same page (in this case, the homepage). Google probably saw that it's being delivered completely different content for different anchors, rather than the expected homepage with an anchor point. It's probably not great from an SEO standpoint. I'm not sure how to account for an anchor in .htaccess rules, but I'm certain you could account for the query string "?" version with apache rewrite rules.

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.