[OzzModz] XFRM File Extension And Size Display

[OzzModz] XFRM File Extension And Size Display 2.0.1

No permission to download

Ozzy47

Well-known member
ozzy47 submitted a new resource:

[OzzModz] XFRM File Extension And Size Display - Show extension type and file size

Another addon brought to you by:
View attachment 203315

This is a simple addon that will show the file extension type and file size in the resource view page. There are no settings for the addon, just install it and forget it.

What it looks like:
View attachment 203316

This addon is also available on my site, https://ozzmodz.com/resources/ozzmodz-xfrm-file-extension-and-size-display.13/

Read more about this resource...
 
Thanks for the great add on... I've been looking for something like this for awhile now!
 
Last edited:
Great modification ... Why do we need to cycle twice in all of this? Why do we need a cycle here? It seems to be a simple addition, but not advisable use of cycles as well as the use of resources. Why did the developers add the possibility of their variables?
HTML:
<dl class="pairs pairs--justified">
                            <xf:if is="count($resource.CurrentVersion.Attachments) == 1">
                                <xf:foreach loop="$resource.CurrentVersion.Attachments" value="$attachment">
                                    <dt>{{ phrase('extensionsize_extention_type') }}</dt>
                                    <dd>{{ $attachment.getExtension() }}</dd>
                                </xf:foreach>
                            </xf:if>
                        </dl>
                        <dl class="pairs pairs--justified">
                            <xf:if is="count($resource.CurrentVersion.Attachments) == 1">
                                <xf:foreach loop="$resource.CurrentVersion.Attachments" value="$attachment">
                                    <dt>{{ phrase('extensionsize_file_size') }}</dt>
                                    <dd>{{ $attachment.getFileSize()|file_size }}</dd>
                                </xf:foreach>
                            </xf:if>
                        </dl>]
It seems to be all simple and quite logical decision, but this is not even knowledge of the syntax of XenForo. Give me a moment to think and oh can you do this
HTML:
$0
<xf:if is="count($resource.CurrentVersion.Attachments) == 1">
  <xf:set var="$attachment" value="{{ $resource.CurrentVersion.Attachments|first }}" />
  <dl class="pairs pairs--justified">
      <dt>{{ phrase('extensionsize_extention_type') }}</dt>
      <dd>{{ $attachment.getExtension() }}</dd>
  </dl>
  <dl class="pairs pairs--justified">
      <dt>{{ phrase('extensionsize_file_size') }}</dt>
       <dd>{{ $attachment.getFileSize()|file_size }}</dd>
  </dl>
</xf:if>
And where are the arrays? Where is busting them. In addition to all this, we write code according to the DRY development principle. In what form we now see all this, we get a waste of resources to nowhere and 2 times through the cycle 1 time to get the type, and the second time to get the size of the file itself. Where exactly in the search of these elements there will be the same result, only with a higher expenditure on memory consumption.

 
Last edited:
Thanks for reporting this. I will look into it and update if necessary.

Great modification ... Why do we need to cycle twice in all of this? Why do we need a cycle here? It seems to be a simple addition, but not advisable use of cycles as well as the use of resources. Why did the developers add the possibility of their variables?
HTML:
<dl class="pairs pairs--justified">
                            <xf:if is="count($resource.CurrentVersion.Attachments) == 1">
                                <xf:foreach loop="$resource.CurrentVersion.Attachments" value="$attachment">
                                    <dt>{{ phrase('extensionsize_extention_type') }}</dt>
                                    <dd>{{ $attachment.getExtension() }}</dd>
                                </xf:foreach>
                            </xf:if>
                        </dl>
                        <dl class="pairs pairs--justified">
                            <xf:if is="count($resource.CurrentVersion.Attachments) == 1">
                                <xf:foreach loop="$resource.CurrentVersion.Attachments" value="$attachment">
                                    <dt>{{ phrase('extensionsize_file_size') }}</dt>
                                    <dd>{{ $attachment.getFileSize()|file_size }}</dd>
                                </xf:foreach>
                            </xf:if>
                        </dl>]
It seems to be all simple and quite logical decision, but this is not even knowledge of the syntax of XenForo. Give me a moment to think and oh can you do this
HTML:
$0
<xf:if is="count($resource.CurrentVersion.Attachments) == 1">
  <xf:set var="$attachment" value="{{ $resource.CurrentVersion.Attachments|first }}" />
  <dl class="pairs pairs--justified">
      <dt>{{ phrase('extensionsize_extention_type') }}</dt>
      <dd>{{ $attachment.getExtension() }}</dd>
  </dl>
  <dl class="pairs pairs--justified">
      <dt>{{ phrase('extensionsize_file_size') }}</dt>
       <dd>{{ $attachment.getFileSize()|file_size }}</dd>
  </dl>
</xf:if>
And where are the arrays? Where is busting them. In addition to all this, we write code according to the DRY development principle. In what form we now see all this, we get a waste of resources to nowhere and 2 times through the cycle 1 time to get the type, and the second time to get the size of the file itself. Where exactly in the search of these elements there will be the same result, only with a higher expenditure on memory consumption.
 
Last edited:
@ozzy47
I’ll gather up courage and ask - is it possible to add the MD5 Sum showing, as it was for version XF 1.x?
 
It can be done, but I would also have to override the sidebar width from 250px to 270px to display it correctly. That may cause display issues on custom styles.
 
override the sidebar width from 250px to 270px to display it correctly
In order not to override the width of the sidebar, just show the last 8-10 characters of the hash sum. For example, Xiaomi does this when compiling its firmware into the archive name:
1587045361843.png
They always match the end of the full hash sum. Verified.
It might look something like this (PS):
скрин1178.png
 
Added in version 2.0.0
I changed the phrase “Hash” to “MD5” so that users don't get confused because the hash-sum are different: CRC32, SHA-1, etc.

скрин1180.webp

In general, a great realization, better than I could have expected, bravo! 👏
You're a "The Wonderful Wizard of Oz"! :giggle:

1587104634480.webp
 
Top Bottom