WCF 2.1 — New, improved and deprecated APIs

  • We've learned about the high level changes for developers so far, but there were also some lower level APIs that are new, improved or deprecated. This spotlight will give you an overview over the most important changes. All these changes require Community 2.1 and will not work in Community Framework 2.0.


    HTTPRequest

    • New maxLength option
      HTTPRequest will abort the request, once it has retrieved maxLength bytes. You are guaranteed to receive at most maxLength bytes if you set this option. This option is useful as a kill switch to ensure the server does not download huge files in case someone tries to DOS you.
    • httpHeaders return value
      This return value is a replacement for the previous headers return value. A big downside of headers was that it only returned the last header of the same type. httpHeaders will always return an array containing all the headers.
    • headers return value deprecated
      headers now is deprecated in favor of httpHeaders

    Undeletable reportable content



    Previously a delete button was always displayed in the report. There are reportable items (such as user profiles) that cannot or should not be deleted. You are now able to override canRemoveContent in your IModerationQueueReportHandler implementation. If this method returns false the delete button will be hidden.


    Detecting the administrator’s control panel via CSS
    The <body> tag of the ACP now has got wcfAcp as a class. You can use this to adapt your styles for the ACP.


    Permissions and options for the sitemap
    The sitemap.xml now supports <permissions> and <options> similar to the pageMenu.xml.


    Diff
    Note: In most cases the edit history is what you need


    The [eea79a3fd1e74796e0d8e6b8c9ad49b1685832cb] class contains the low level API that backs the template diff and the edit history. Note that the class is not limited to strings, in fact you have to convert your strings to an array first.


    <APP>_INSTALL_DATE is automatically populated
    Community Framework 2.1 will automatically populate the <APP>_INSTALL_DATE option during installation of an application. The requirements are that: a) You explicitly ship the option with your application b) It has got the type integer


    New format for <body> id
    As you Community Framework 2.1 you should use <body id="tpl_{$templateNameApplication}_{$templateName}" data-template="{$templateName}" data-application="{$templateNameApplication}"> (or: <body id="tpl{$templateName|ucfirst}" data-template="{$templateName}" data-application="{$templateNameApplication}"> for legacy templates) instead of <body id="tpl{$templateName|ucfirst}">


    {$__wcfVersion} replaced by LAST_UPDATE_TIME
    Beginning with Community Framework 2.1 you should use LAST_UPDATE_TIME instead of $__wcfVersion to bust the browser’s JavaScript cache.
    @
    Old: <script src="{@$__wcf->getPath()}js/WCF.js?v={@$__wcfVersion}"></script>
    New: <script src="{@$__wcf->getPath()}js/WCF.js?v={@LAST_UPDATE_TIME}"></script>


    __literal for {lang}
    This only affects you, if you are using template scripting in language variables used by JavaScript. Previously one had to wrap the entire variable in {literal} tags to avoid mangling the contents. No you can simply use: {lang __literal=true} to achieve the same.


    An example is the wcf.like.jsTooltip language item. It is dynamically created by a template scripting subset in JavaScript. Because the syntax is the same PHP will attempt to parse it, if it is not wrapped in a literal-Tag: {literal}{if $likes}{#$likes} Like{if $likes != 1}s{/if}{if $dislikes}, {/if}{/if}{if $dislikes}{#$dislikes} Dislike{if $dislikes != 1}s{/if}{/if}{/literal}. As of Community Framework 2.1 you can omit the literal-Tag and instead use the __literal parameter.


    Application guessing for several classes


    DatabaseObject, AbstractApplication, AbstractCategoryType, AbstractDeletedContentProvider, AbstractSearchableObjectType and AbstractTaggable will automatically detect whether the implementation belongs to an application and adapt their database prefix and other things with the proper abbreviation.


    AtomicWriter


    Commmunity Framework 2.1 provides a new AtomicWriter to write a file atomically. You should use this class when you have files that should never be half written. The AtomicWriter ensures that: a) Either the file is written or it is not, there will never be only parts of it b) Parallel requests will not write to the same file and destroy it. It basically works like the File class, it however only support writing operations. You cannot read from an AtomicWriter. In order to commit the file you have to call the flush() method, otherwise the contents will be discarded.


    TemplateListenerCacheBuilder and VersionableDatabaseObject system deprecated


    Both were never actually used in Community Framework 2.0 and may contain unfixed showstopper bugs. You should not use them, they will be removed in a future version. We recommend taking a look at the edit history to replace the VersionableDatabaseObject system.