ryan

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.

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.