Jump to content

Need your help


Stephane

Recommended Posts

Hi,

I installed the latest BETA version to test, but I'm not able to reproduce what I was doing in IP.Content. Just a few lines

<if test="is_array( $records ) && count( $records )">
<foreach loop="$records as $r">
<if test="$r['my_variable'] == 'mytest'">My text</a></if>
</foreach>

</if>

I dont find my variable name... oufff thank's for your help.

Stef

Link to comment
Share on other sites

I have read, but the content is not unsuitable for "PAGES".

In my custom template "listing" if I want to use a variable, I use

{$row->customFieldDisplayByKey('my_key')|raw}

But the problem is that I still have the name of the field: and value. I am not able to have only the value.

If I remove "|raw" I have the html code with name of the field: and value

Is it possible to have only a value?

Thank's in advance for your help...

Link to comment
Share on other sites

I have read, but the content is not unsuitable for "PAGES".

In my custom template "listing" if I want to use a variable, I use

{$row->customFieldDisplayByKey('my_key')|raw}

But the problem is that I still have the name of the field: and value. I am not able to have only the value.

If I remove "|raw" I have the html code with name of the field: and value

Is it possible to have only a value?

Thank's in advance for your help...

​Choose "Custom format" and only add the value there.

Like this; http://puu.sh/dIg2T/a8adbd5e41.png

Link to comment
Share on other sites

  • 2 weeks later...

Bumping this.

When in Pages and messing with database fields IPS gives the code for HTML template output on that field using the designated field key, namely

{$record->customFieldDisplayByKey('my_key')|raw};

If you are in a listing template - specifically recordRow - the record has already been extracted out to $row however.

No problem, as Stephane has already worked out, you just change the $record to $row in that provided snippet and you get what you need.

The nut is as he says though. That altered snippet now provides Field Name: Value as one whole entity, regardless of any formatting choice you selected when formatting the field in the ACP. With the 3 series we had access to both field name and field value (and more). I don't think this is a bug; we're just missing

For the provided listing template, the field flagged as title is href linked to the record and the field flagged as content is not displayed - I have a bug report in on these as formatting options are not exposed for these flagged fields meaning you have to do a dance to get at the key values of those fields if you haven't already written them down somewhere.

For the remainder of the listing template, the following code is used:

{{if count( $row->customFieldsForDisplay('listing') )}}
                <div class='ipsDataItem_meta'>
                {{foreach $row->customFieldsForDisplay('listing') as $fieldId => $fieldValue}}
                    {{if $fieldValue}}
                        {$fieldValue|raw}
                    {{endif}}
                {{endforeach}}
                </div>
            {{endif}}

As he says, $fieldValue will correctly pull the as-formatted in the ACP field value correctly, and the un-edited snippet using $record works great when you are in a display template for a single record as the template itself is not iterating over $row but using $record. 

I guess we need something on the backend to cover $row just as $record is accounted for. I wonder if I change the {{foreach $rows as $row}} to {{foreach $rows as $record}} and edit the rest of the template accordingly if that would get it to fire off. That's probably the 2:36am talking though :)

 

Link to comment
Share on other sites

Well now that the cobwebs are cleared I can help a bit more.

1) Flipping all the $row calls to $record as put forth above works fine - all it is doing is just changing the internal variable name - but does not fix the problem.

{$record->customFieldDisplayByKey('my_key')|raw};

That code, without looking under the hood, seems to provide "field name: value" no matter how you have it structured in the format tab for a field. Is that a bug or working as intended? No idea. IPS would need to chime in at this point.

2) Still a solvable problem but a bit of a throw back to the 3 series. Still works fine though. Bring up phpMyAdmin or whatever you use to inspect your database structure. Navigate to cms_custom_database_???? as needed. Slide on down to find the fields that are just named field_# - those will, just like the 3 series, be just numbered fields that correspond to the fields in your custom database. You should easily be able to tell what the field holds by browsing. To call up the *value* of the field, plain text, unformatted:

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

Replacing # with the needed # for your field.

If customFieldDisplayByKey is working as intended and not providing the formatted in the ACP value for the fields it shouldn't be too much work for IPS to give us an additional function here that passes the formatted version. Again, this might be a bug (I'm submitting in a moment to get clarification) but no matter what the above workarounds should always work. Especially useful in cases where you will be displaying the same variable more than one time on the same page but you do not want to be locked in to the formatting you applied to the field in the ACP.

 

 

Link to comment
Share on other sites

 

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

Replacing # with the needed # for your field.

Ah, thanks! That is useful. I was also struggling with the ​CustomFieldDisplayByKey. 

By the way: you don’t need to use phpMyAdmin to look up the IDs. Just as in 3.4, go to the database settings and in the field overview the IDs appear in the URLs when you hover over the edit buttons. 

Link to comment
Share on other sites

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

​Thank's.... Fantastic... :thumbsup:

Link to comment
Share on other sites

Wow, that took me longer to find than I thought it would.

For anyone else, when you are looking at the list of fields in a custom Pages database and you hover over the button to edit the field, the bottom of your browser will display the URL that button is going to call when you click it. You may have to wait a moment for the URL to completely build out but the very last bit at the end:

.....database_id=2&do=form&id=12

The last id call at the end. In this case the field call would be field_12

Clever way to get at it. Would be killer if this was an actual hover popup instead :)

Link to comment
Share on other sites

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:

http://community.invisionpower.com/4bugtrack/beta-4b-pages-customfielddisplaybykey-formatting-r1347/

http://community.invisionpower.com/4bugtrack/beta-4b-customfielddisplaybykey-appending-method-bug-r1389/

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 1 year later...
On 6 de janeiro de 2015 at 4:08 PM, Flitterkill said:

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.

Thanks a lot!

Link to comment
Share on other sites

FYI

Quote
  • Ability to use $record->field_key_name_here programatically to get and set values, instead of relying on $record->field_11 which may change when you export and import databases.

This is new in 4.1.13.x.

So some of the junk I posted months ago might be easier now.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...