ryan

Thanks, I sometimes forget we support uppercase chars in field names (I don't use them myself). We can't support uppercase in permission names, since they are ultimately page names. But I think I can make this case insensitive. This won't be a problem, as you can't have two fields with the same name from the DB side, of different case. Can you tell me if this update fixes it for you? https://github.com/ryancramerdesign/PageEditFieldPermission/commit/449dee6eabd3e7adc733ae829568f1828a5d87b5

Joss, I love the wording on your flyer. But is "advertsing" a British spelling (or humor... err humour?), or is that a misspelled word?

Not currently. Though I suppose you could create a module to hook the relevant components to do this. But the custom header name has come up as a repeated request, so this will be added pretty soon. The ability to have the items collapsed has also come up before, though not necessarily to have some collapsed and some not, but I'll look into it.

This is not planned for 2.3. Inclusion in 2.4 or 2.5 is more likely.

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)?