• Content count

  • Joined

  • Last visited

About Flitterkill

  • Rank
    Advanced Member

Profile Information

  • Gender Male

Recent Profile Visitors

15,244 profile views

Flitterkill's Activity

  1. Flitterkill added a post in a topic: Theme System - Missing Vital Functionality   

    Spectacular all around!
    IP.Pages could maybe use some of that custom field type love as well (unless I'm missing that functionality somwhere...)
  2. Flitterkill added a bug in IPS4 Bug Tracker   

    [Beta 5a] "Edited by" line hard-coded HTML strong wrapped
    <strong>Edited <time datetime="2015-01-22T06:09:39Z" title="01/22/15 01:09  AM" data-short="14 min">14 minutes ago</time> by member_name</strong> The above is outputted by {$comment->editLine()|raw} in the post template to display the "edited by member_name" line. It kicks out with opening and closing strong html that are added internally as part of the line. If we are trying to style this line the hard coded <strong> html is a bit of a barrier as it isn't part of the template. Can we get the auto-appended strongs pulled from this? For the default IPS skin you can just add a span with a class that bolds the text instead.
    • 0 replies
  3. Flitterkill added a post in a topic: Question for devs re: widget permissions   

    Thanks Andy - very different from the 3 system. Seems better through and through - just would never have looked there at first glance. 
  4. Flitterkill added a post in a topic: Question for devs re: widget permissions   

    Thanks! So it's under staff section. Ok, I can see why I missed that. And I see there is also some granularity for administrators as well. Still, suppose I had a situation where there are some people I want to have access to the ACP . Some to handle the Commerce section. maybe a person or two to wrangle just forums. That's not rolled out for 4.0 yet is it? Admin is all ACP or nothing?
  5. Flitterkill added a post in a topic: Question for devs re: widget permissions   

    ​Can you find it? I can't find anything in the ACP myself...
  6. Flitterkill added a post in a topic: Question for devs re: widget permissions   

    Actually meant this:

    Having people who have permission to deal with some stuff in the ACP is fine but I can see some people going nuts with block manager not realizing they are changing it for everyone.
    We don't have ACP granular permissions do we? It's all or nothing right now I think.
  7. Flitterkill added a post in a topic: Question for devs re: widget permissions   

    Is there a place (or any way at all) to lock down permissions on who has access to the widget configuration/placement flyout tab. You know, the drag and drop thing for sidebar blocks?
    I'm missing something somewhere right? It's not just available to all administrators right? Actually, do we have any ACP controls besides administrators = all access?
  8. Flitterkill added a post in a topic: Theme System - Missing Vital Functionality   

    We brought up the font/js stuff in the alpha site and someone on staff was going to "think on it" - that's not meant as a dig; just to note it's been out there for awhile.
    All we need really is a duplicate of the image system already present in the theming section. The functionality is already there. Dupe it twice. Fonts. JS/misc. Done! (Or conversely change it to a single add-ons pile to handle fonts, images and js, etc. and manage the rest internally)
    Without this though and skin packs are almost certainly going to have to be more than just a single portable xml file unless as Tom pointed out above we start using the image section in an un-intended manner.
  9. Flitterkill added a post in a topic: Possible to enable thread description on hover?   

    Chrome is fine here; stock. The delay before the hover popup used to be almost instantaneous. This drove people nuts on the old Alpha site so it got backed off to 3-4 seconds of hover before firing.
    I'd clear your browser caches for IE and Chrome before trying anything else. But the hovers have worked (and still work) forever.
    Also, try hovering over a user's icon. Should get the popup user profile.
  10. Flitterkill added a post in a topic: Beta 5 soon?   

    Man, ask a simple question get a three page thread out of it
    Checking right now there are only 30 pending bugs in the tracker. Impressive. That's barely more than a page.
    Looking forward to 5, RC (and Chat) can't be far after.
  11. Flitterkill added a post in a topic: Need your help   

    And to finish beating this dead horse. In listing templates if a field is marked as title or content that function will not fire. You'll need to pull that info directly with  {$row->field_#|raw}  or  {$row->_title|raw}  or  {$row->_content|raw} . Might need to do the same in display view (with $record instead of $row) - haven't looked yet.
    We might get some more exposure of the custom formatting in a future beta/release. Ideally (personal opinion) the customFieldDisplayByKey should just work for all custom fields no matter what/where as long as the db is exposed.
  12. Flitterkill added a post in a topic: Beta 5 soon?   

    It's been a few weeks with 4b. Any news on this front or when it shows up it show up?
  13. Flitterkill added a post in a topic: Need your help   

    Sorry, the second option for formatted should be:
    IN RECORD DISPLAY TEMPLATES: {$record->customFieldDisplayByKey('FIELDNAME','display')|raw} OR {$record->customFieldDisplayByKey('FIELDNAME','listing')|raw}
    Put 'display' down twice.
  14. Flitterkill added a post in a topic: Need your help   

    Got some more on this.
    For the plain, un-formatted value of a field:
    IN LISTING TEMPLATES: {$row->field_#|raw} - specifically in the recordRow template, within the primary foreach loop
    IN RECORD DISPLAY TEMPLATES: {$record->field_#|raw} - in the record template; probably the others as well
    For the *formatted* version of the value of the field as set in the Pages ACP :
    IN LISTING TEMPLATES: {$row->customFieldDisplayByKey('FIELDNAME','display')|raw} OR {$row->customFieldDisplayByKey('FIELDNAME','listing')|raw}
    IN RECORD DISPLAY TEMPLATES: {$record->customFieldDisplayByKey('FIELDNAME','display')|raw} OR {$record->customFieldDisplayByKey('FIELDNAME','display')|raw}
    Couple of things here. Matt responded to my bug report indicating that there is a second passed variable to this function - listing or display - that pulls the formatting you set for the field. The other is that there probably is a bug in the actual function. To get customFieldDisplayByKey to function correctly you'll need to edit applications/cms/sources/Record/Records.php around line 863. There is a line there that is appending the word Method to the passed listing or display variable. Old debug code? Something else? Don't know. Reported as a bug. But if you want this to work right now find $type .= "Method"; at line 868 or so and delete it. You can leave the if statement intact if you like. Whether that's the real fix or not we'll find out but the important thing is that this functions wonderfully. 
    Once you hack that out and get this working correctly know that the default value for the function is the *display* formatting. You can see that coded in when you delete that line above. So if you don't pass anything other than the fieldname, it will format as set in display. 
    Might be a fun hook or future IPS enhancement built in where we can add in additional format options right there when editing the field format in the ACP so we are not limited to just the listing or display formats but can add one or more of our own, Shouldn't be that hard at all.
    BTW, as it says right there when entering a custom format for field, the IPS php stuff is good to go. If/then conditionals, etc. Works great!
    For reference, the bug reports:
  15. Flitterkill added a bug in IPS4 Bug Tracker   

    [Beta 4b] customFieldDisplayByKey appending METHOD bug
    First, so much love for this feature. After Matt explained there is a second function variable you can push to fire off the custom formatting set in the ACP here: http://community.invisionpower.com/4bugtrack/beta-4b-pages-customfielddisplaybykey-formatting-r1347/  I tried for longer than I care to say to get the thing to fire off. No permutations of the second variable (display or listing) would get anything done. 
    Looking over the code in records.php I couldn't understand why METHOD was being appended to the $type variable. Didn't seem right, took a chance, nuked it, and all now works gloriously as intended. Gloriously!
    Starting at line 863:
    public function customFieldDisplayByKey( $key, $type='display' ) { /* As we're fetching a single item, then we can bypass skipping fields we're hiding from this view */ if ( $type === 'listing' or $type === 'display' ) { $type .= "METHOD"; } if ( ! isset( $this->customDisplayFields[ $type ] ) ) { $this->customFieldsForDisplay( $type ); } return isset( $this->customDisplayFields[ $type ][ $key ] ) ? $this->customDisplayFields[ $type ][ $key ] : FALSE; } Removing that METHOD append solved everything. If this is breaking something else I can't see it. 
    • 0 replies

Status Feed