Liam Dilley wrote:

 

Passed paramaters can not have filters applied to them.

 

{{params.fItemCheck | downcase }}

This is ignored

 

Also if you have a use case where you are comparing a paramater to a web app item name for example:

 

{% if params.fItemCheck == name %}

Even if you output them and they are exactly the same - This condition is never met.

 

You can not use an assign on a passed paramater either..

 

{% assign thisThing = params.fItemCheck %}

 

{{thisThing}} would just render out inline.

Hey Liam.

Can you please create a page where this issue is duplicated?

I'm trying to duplicate these issues and I can't. I tried it with a page with:

{module_contentholder name="params" param1="test"}

And in the content holder I have:

<div>

    {{params.param1 | upcase}}<br/>

    {% if params.param1 =='test' %}

    Test works

    {% endif %}

</div>

And all works well.

Scott Shefler wrote:

 

After further testing there seems to be more issues with the less than operator “<” it works in my example above but then when I do something like below it does not work. It render nothing but a trailing “<” less than operator. There seems to be some issues with the less than symbol rendering or being encoded.

 

 

{% for item in medialibrary.items %}

{% if item.counter < 3 %}

{module_webapps id="Media Library" filter="item" itemId="{{item.itemid}}" hideEmptyMessage="true" template="/ModuleTemplates/WebApps/MediaLibrary/List/testimonials.tpl"}

{% endif %}

{% endfor %}

Hey.

Thanks for the report. We have 2 issues with numeric types that we're working on fixing now. One is related to the fact that some modules incorrectly return string type instead of numeric, which makes the comparison break, and another related to float (decimal point) type.

We'll do a release soon to fix these things.

Hey Lucian, in general debugging and testing out liquid is taking a ton of time. Time in which is hard to come by when we have client work that needs to get done. There are so many issues I'm running into and this is making development difficult when I don't know if it's a bug or if it's just learning how to code with liquid. Also, documentation is not good which is making this even harder. To ask us to isolate every issue on a separate environment will take more time. I'm not sure if that's reasonable. If there are specific bugs you can't replicate I think it would be best to reach out individually so we can help you with that specific instance. Thanks!

Scott Shefler wrote:

 

Can't seem to get the back up template for web apps to work. Nothing is being rendered whether I put useBackupTemplate="true" or useBackupTemplate="false" or leave it empty. Also, documentation is not very clear on how to use the normal list layout. I don't think it's obvious to the typical user that removing useBackupTemplate="" and not adding template="" or collection="" will just render the typical list layout. Should be specified more clearly. Ideally I think there should be one tag that specifies them all: template="collection.nameofcollection" template="default" (list,default,primary are other options) template="backup" template="/path/template.tpl"

Hi.

The useBackupTemplate parameter is something no longer needed for a module now since you can specify in the "template" attribute the template which you want to use.

That parameter was there since the time you could not specify the template of a module (allowing you to have something like a second template to the module).

The way this works now is this:

• If you don't put in a template="" param, the module will render with the default template
• If you don't put in a template="" param and also use useBackupTemplate parameter, the module will render with the backup template.
• Whenever you specify template="/mytemplate" the module will use that template to render (and completely ignore the useBackupTemplate parameter)

The fact that it does not render the module because of that parameter is a bug though and it will be fixed.

The idea though would be do completely discontinue the useBackupTemplate named parameter. It's useless now that you can specify a template. So I would advise not using it as a named parameter any more, just use the template="" param to specify what is the template you want to use.

Scott Shefler wrote:

 

Hey Lucian, in general debugging and testing out liquid is taking a ton of time. Time in which is hard to come by when we have client work that needs to get done. There are so many issues I'm running into and this is making development difficult when I don't know if it's a bug or if it's just learning how to code with liquid. Also, documentation is not good which is making this even harder. To ask us to isolate every issue on a separate environment will take more time. I'm not sure if that's reasonable. If there are specific bugs you can't replicate I think it would be best to reach out individually so we can help you with that specific instance. Thanks!

Hey Scott. I understand that this can be difficult (identifying bugs is never easy).

If you're not able to isolate this thing separately on a page/test site, at least try to put the URL of the page where you've duplicated the issue so that we can take a look at it and zero-in on the problem.

You have to understand that it’s also not easy for out team to go back and forth on e-mail on all of these things (especially with timezone difference and wait time that it takes and misunderstandings in e-mail). We can do it (we already did it and will be doing them in some cases), but that’s just not going to work well if we always have to go that route.

Besides, having these issues posted here for everyone to see and track would make everyone aware of the issue, help with feedback (maybe duplicated in another context) and even not re-post the same thing (which if all these things would be done one-on-one will not be possible).

We’re also working on documentation to make it better and i hope things will become more and more easy.

Thank you,

-Lucian

OK. I figured out what the problem is. It does work, however, I had to put the

{module_webappscustomer id="25235" filter="a" collection="someID" template=""} above anything that you want to render json for. I had this module at the bottom of my page, and the form was above. Once I moved the {module_webappscustomer id="25235" filter="a" collection="someID" template=""} to the very top of my page/code above the form, the json data was available to anything below it including the form.

This can be tested easily by placing the <pre>{{this | json}}</pre> at the top of the page and having any module that you want json data for below it. It will not show the data. But id you place the <pre>{{this | json}}</pre> at the very bottom of the page, below all modules, the json data becomes available. After looking at the documentation I see that the examples show to put the <pre>{{this | json}}</pre> at the bottom of the page to see what data is available.

Lucian, understood this is difficult from both ends. Providing you with the URL is not going to work for me though. The only way I have time to test the new liquid and find these bugs is by building live sites with it. If I encounter a bug I have to find a workaround or use another method. I can't leave it in there broken for you to test. I like this thread for bugs but there is a lot of other back and forth communications that aren't bug reports. This should be a place where we can all see everyone's communications but ideally I think you guys should isolate the bugs and create a public document that lists out all confirmed bugs so we can see if they've been reported thus far and so they aren't repeated on these forums.

Not sure if this is really a bug or how the system renders now but I can see this being an issue. If you are outputting a collection of web app items but there are no web app items in that collection and you try to use liquid to call something inside the collection it will not render. It will just render the liquid tag.

For example:

{module_webapps id="Media Library" filter="all" hideEmptyMessage="true" sortType="date" resultsPerPage="2" collection="medialibrary" template=""}

{% for item in medialibrary.items %}

     <div class="item">{{title}}</div>

{% endfor %}

Then I'm trying to just call the first item id like:

{{medialibrary.items[0].itemid}}

if there are items in the collection then {{medialibrary.items[0].itemid}} renders 123456 (item id)

If there are no items in the collection then {{medialibrary.items[0].itemid}} render {{medialibrary.items[0].itemid}}

I know we can run an if statement like:

{% if medialibrary.items %}

{{medialibrary.items[0].itemid}}

{% endif %}

But wouldn't it be better that if the collection item doesn't exist to render nothing instead of rendering a broken liquid tag? Is this possible?

But wouldn't it be better that if the collection item doesn't exist to render nothing instead of rendering a broken liquid tag? Is this possible?

Causing tags that refer to nonexistent or null properties to render nothing instead of visibly failing is a terrible idea and will make debugging much harder.

It would only be acceptable if there were a filter for it, like {{ medialibrary.items[0].itemid | hideEmpty }}.

Personally I think this is a really poor facility to use for  bug/enhancement tracking. It still amazes me that we don't use a dedicated bug tracking tool like every other software provider. I feel like a broken record bringing it up.

Yeah Liam, that is strange that you can't replicate it. At least it works when I moved my {module_webappscustomer id="25235" filter="a" collection="someID" template=""} above all other code on the page, or at least the point where you try to access it with liquid e.g. {{someID.items[0].itemid}}. Maybe this is supposed to be this way. Just wasn't aware of it.

This works -

{module_webappscustomer id="25235" filter="a" collection="someID" template=""}

{{someID.items[0].itemid}}

This Doesn't -

{{someID.items[0].itemid}}

{module_webappscustomer id="25235" filter="a" collection="someID" template=""}

Lucian Cozma wrote:

 

Scott Shefler wrote:

 

Can't seem to get the back up template for web apps to work. Nothing is being rendered whether I put useBackupTemplate="true" or useBackupTemplate="false" or leave it empty. Also, documentation is not very clear on how to use the normal list layout. I don't think it's obvious to the typical user that removing useBackupTemplate="" and not adding template="" or collection="" will just render the typical list layout. Should be specified more clearly. Ideally I think there should be one tag that specifies them all: template="collection.nameofcollection" template="default" (list,default,primary are other options) template="backup" template="/path/template.tpl"

 

Hi.

 

The useBackupTemplate parameter is something no longer needed for a module now since you can specify in the "template" attribute the template which you want to use.

That parameter was there since the time you could not specify the template of a module (allowing you to have something like a second template to the module).

 

The way this works now is this:

• If you don't put in a template="" param, the module will render with the default template
• If you don't put in a template="" param and also use useBackupTemplate parameter, the module will render with the backup template.
• Whenever you specify template="/mytemplate" the module will use that template to render (and completely ignore the useBackupTemplate parameter)

 

The fact that it does not render the module because of that parameter is a bug though and it will be fixed.

The idea though would be do completely discontinue the useBackupTemplate named parameter. It's useless now that you can specify a template. So I would advise not using it as a named parameter any more, just use the template="" param to specify what is the template you want to use.

Not sure if what you mean by "The fact that it does not render the module because of that parameter is a bug though and it will be fixed." is that any .html file not work in template="?????/????.html". But if not there is another issue.

Using template="/mytemplate" for the list_backup.html does not work you have to replace html with tpl then it is not longer editable in the webapps Alternate list in the CMS. So you are forced you to use the old module syntax ,,,,,,,,.

Can this please be looked at.

{module_url param="type"} Does not work when inserted in attribute elements.

For example:

<div data-tagurl="{module_url param="type"}"> Does not work

<div data-tagurl='{module_url param="type"}'> Does not work

<div data-tagurl="{module_url param='type'}"> Does not work

These all render <!-- module_url param="type" could not be parsed because the parameters are invalid. -->

When I place it on the page regularly it renders fine.

Digital Fuel Web wrote:

 

Lucian Cozma wrote:

 

Scott Shefler wrote:

 

Can't seem to get the back up template for web apps to work. Nothing is being rendered whether I put useBackupTemplate="true" or useBackupTemplate="false" or leave it empty. Also, documentation is not very clear on how to use the normal list layout. I don't think it's obvious to the typical user that removing useBackupTemplate="" and not adding template="" or collection="" will just render the typical list layout. Should be specified more clearly. Ideally I think there should be one tag that specifies them all: template="collection.nameofcollection" template="default" (list,default,primary are other options) template="backup" template="/path/template.tpl"

 

Hi.

 

The useBackupTemplate parameter is something no longer needed for a module now since you can specify in the "template" attribute the template which you want to use.

That parameter was there since the time you could not specify the template of a module (allowing you to have something like a second template to the module).

 

The way this works now is this:

• If you don't put in a template="" param, the module will render with the default template
• If you don't put in a template="" param and also use useBackupTemplate parameter, the module will render with the backup template.
• Whenever you specify template="/mytemplate" the module will use that template to render (and completely ignore the useBackupTemplate parameter)

 

The fact that it does not render the module because of that parameter is a bug though and it will be fixed.

The idea though would be do completely discontinue the useBackupTemplate named parameter. It's useless now that you can specify a template. So I would advise not using it as a named parameter any more, just use the template="" param to specify what is the template you want to use.

 

Not sure if what you mean by "The fact that it does not render the module because of that parameter is a bug though and it will be fixed." is that any .html file not work in template="?????/????.html". But if not there is another issue.

 

Using template="/mytemplate" for the list_backup.html does not work you have to replace html with tpl then it is not longer editable in the webapps Alternate list in the CMS. So you are forced you to use the old module syntax ,,,,,,,,.

Can this please be looked at.

You can still use template="/???/list_backup.html"  to use the backup list template (or any other default or non-default .html template) when using liquid. In fact, there is no requirement to use a .tpl extension.  It's just a generally agreed upon best practice.  So if I were you I would just forget the useBackupTemplate parameter ever existed.  There is no point in using it with liquid and it was a very short sighted feature to have added it in that manner from the beginning. I expect it to be deprecated and removed from the front end as well some time in the future.

As for the bug, my understanding is that if you add the useBackupTemplate parameter and also add the template parameter in liquid, the "template" parameter should actually overrule the "useBackupTemplate" parameter in all cases and the module should render as if the useBackupTemplate parameter was never added.  Apparently that's not happening.  Again, why bother doing it all though.

New Admin Editor Bug:

In HTML5, the li and p tags are not required to have closing tags.  However, If you add code like below, the editor wrongly alters your code by adding closing tags to the li elements anyway after saving:

<ul>

<li>One

<li>Two

<li>Three

</ul>

You can confirm this problem by opening the file using the Develop tab editor.  (Don't do a DOM Inspection in the browser because it will always appear to show the closing tag. You would have to choose View Source.)

Altering the code like this should never happen.  This is especially bad because for modern responsive web layouts which use inline-block or inline-table instead of floats, the preferred and only non-hacky way of getting rid of the extra space between the list items is to just not add the closing tags.  In BC apparently you can't do that.  BC's admin editor forces the designer to use floats or hacks if you want to use it. 

No admin editor should ever require you to use floats for layout.  The current ICE editor has the same buggy behavior.

Liam Dilley wrote:

 

Daryl, I think you missed why you use .tpl. It is not a best practise thing. It is to stop it appearing as a .html page file which would be picked up in several ways by BC as it would treat it as a web page.

I'm quite aware of that.  That's why it's a best practice.

Liam Dilley wrote:

 

Hey Daryl,

Not sure where you read that HTML5 does not need closing tags like that.

Your getting some concepts mixed up.

Even in html4 in theory you do not need to close tags off, not just html5 IS it best practise or is valid semantic markup and is it something most html parses validate? Nope, even W3 will mark the code as invalid, and webkit based browsers will give you a hard time. I think Opera and Firefox are the only browsers that handle that concept well.

So what your trying to do there is actually a big "nono" of course that wont work and I wont class that as a bug. It is brad practise and people should not be trying to code their html like that.

 

What you do have with HTML5 that is acceptable is self closing etc and this is something people are adopting, and I think this is what your originally thinking over say XHTML.

 

So you have an input or image for example:

 

<input type...... />

<img src=""...../>

 

You do not have to provide the <input src="".... >

 

If you try and code as you posted your going to be in a world of hurt from liquid, php, html, javascript..... nonononono

I'm sorry Liam but you're giving incorrect info.  In both HTML4 and HTML5, the </li> closing tag is not required and all browsers handle it perfectly including Webkit and IE.  Even very old versions.   You are also wrong about the W3 validator marking the code as invalid. It does not.   A simple test would have confirmed that for you.  I'm not sure where you got that from that it was invalid or that the validator was marking it as invalid.  This has nothing to do with self closing tags like input and img.  I'm afraid you're getting things mixed up, not me.

Here's some reading you might want to catch up on HTML5 standards regarding this:

li – list item - HTML5

https://developers.whatwg.org/grouping-content.html#the-li-element

html5 - HTML: Include, or exclude, optional closing tags? - Stack Overflow

Both the WhatWG and W3 specifically and explicitly state that the closing tag for li and p (and a few others) are NOT required.  This is pretty common knowledge.

In fact, some of the W3 examples omit the tags when explaining how to mark things up:

The global structure of an HTML document

So no, the admin editor should not alter the valid code written by the developer for the reasons I gave previously regarding modern web design layouts.

It appears that the display random webapp items are not working anymore.

Neither of these work.

{module_webapps,22787,r}

{module_webapps id="22787" filter="r"}

I say "appears" because I refreshed the page a good 20 to 30 times, and it still only displays the last item of the webapp.

Look, Liam I don't want to get into a back and forth with you.  What you are saying is simply incorrect and going completely against what experts in the field say... namely the ones who set the standards.  The W3 and WhatWG specifically state you do not have to include the closing tag for li.  They even use it that way in their examples that have nothing to do with closing tags so it is not frowned upon in any way. Otherwise, the standards bodies wouldn't use it in examples.  It is definitely not invalid as you claimed nor is it marked as invalid in the W3 validator.  I'm not sure why you keep repeating that when anyway can clearly fact check both for themselves.

As for editors that don't alter the code, BC's editor in the Develop toolbar does not add the closing tag.  Nor does Adobe Brackets or Sublime.  Heck, even Dreamweaver doesn't.  No code editor I use adds the closing tag for li if you don't add it yourself.

I'm sorry Liam but web standards is my forte' and it really bothers me when people get web standards wrong and make emphatic public statements about it.  Mostly because there are others who might be still learning and reading incorrect information.  There is a specific reason why the closing tag for li is not needed and this decision was not made lightly by the experts setting the standards.  Again, this is a best practice and only way to do modern layouts with inline-block without hacks.

You might want to get caught up on HTML5 a little bit more regarding what's allowed and not allowed.  I posted a few links earlier that might help you get up to speed.

Anyway, this is not the time nor place to discuss the standards.  At the end of the day, one of the main points of the new editor is to fix the problem where the old editor would alter the code as intended by the developer.  In this case it most certainly is altering fully valid code and an editor should never alter valid code unless specifically instructed to do so by the developer.

As I said using template="???/list_backup.html" is not working for me.

To test I have copied the list_backup.html file and renamed it list_backup.tpl I have the altered the template="???/list_backup.html" to template="???/list_backup.tpl" and it works. I can change just the html to tpl and then tpl to html to make it work and not work. I get tpl but this does not change the fact that list_backup.html it is not seemingly working in this instance so looks like a bug.

Yes Liam, we will just have to agree to disagree. It's not bad practice and I have pointed this out with actual documentation and examples from the standards bodies.  If you don't agree with the standards bodies that's fine but I have been asked and have presented on web standards and best practices as well including at Adobe Max and have been asked to be on the Advisory Board for an application in the Adobe Web Platform.   Heck, I have written an entire responsive framework from the ground up so I know what I'm doing and I don't appreciate you wrongly claiming my code as invalid, challenging my coding practices,  telling me to "up my game", or any other thinly veiled shots you took at me from the very beginning.  None of that had anything to do with the bug I reported and was not only incorrect but simply unprofessional.

And it's not just me.  I've seen you do this with other people on here as well.  I appreciate your contributions to BC but in a lot of ways you're actually hurting the BC community.  You're not the only one in the world who knows how to code and the way you sometimes go about things seems to discourage others who have a lot to contribute from participating.  If BC is going to grow and challenge some of the more established competitors out there, it is going to need a much larger community of knowledgeable people contributing.  And that should be good for everyone involved.

Look, all I'm saying is try and be a little more tactful in your responses and especially when things are not addressed to you in particular. But yes I agree that this is getting off topic so we will leave the conversation there.

filtering by latest Webapp items not displaying more than ten items. I have 20 items total that I am trying to display.  When I change the number to lets say "8" then it will display 8 items with pagination, but on the second page I have only 2 items displaying. again only totaling 10 items.

Doesn't Work -

{module_webapps id="25143" filter="l" resultsPerPage="20"}

Doesn't Work -

{module_webapps,25143,l,,,,,20,true,,}

When updating a webapp item (update web app item) using the api, I noticed that when a status code of 200 is returned and the item is updated successfully, it still triggers the .fail() and will not execute the .done() or .then() etc. In order to fix this I had to put a data type of "html" in my ajax call.

When updating the web apps categories using the api, I don't have to specify a data type it works just fine. Below is not the complete code, but it is the core to see what I am talking about

This works -----

var idVAR = itemDetails.get('id')

var NAME = itemDetails.get('name')

var request = $.ajax({

    url: '/api/v2/admin/sites/current/webapps/' + WEBAPP_NAME + '/items/' + idVAR + '',

    type: "PUT",

    connection: "keep-alive",

    dataType: "html",

    contentType: "application/json",

    headers: {

        "Authorization": $.cookie('access_token')

    },

    data: JSON.stringify({

    "name": NAME,                

    "fields": {

        "userID": PID

    }

})

});

request.then(updateItem);

function updateItem(){

    console.log("3 Update successful");

    converted(itemDetails);

}

request.fail(function (jqXHR) {

    console.log("Request failed.");

    console.log("Error code: " + jqXHR.status);

    console.log("Error text: " + jqXHR.statusText);

    console.log("Response text: " + jqXHR.responseText);

})

This Works, but returns the .fail() ----

var request = $.ajax({

    url: '/api/v2/admin/sites/current/webapps/' + WEBAPP_NAME + '/items/' + idVAR + '',

    type: "PUT",

    connection: "keep-alive",

    contentType: "application/json",

    headers: {

        "Authorization": $.cookie('access_token')

    },

    data: JSON.stringify({

    "name": NAME,                

    "fields": {

        "userID": PID

    }

})

});

request.then(updateItem);

function updateItem(){

    console.log("3 Update successful");

    converted(itemDetails);

}

request.fail(function (jqXHR) {

    console.log("Request failed.");

    console.log("Error code: " + jqXHR.status);

    console.log("Error text: " + jqXHR.statusText);

    console.log("Response text: " + jqXHR.responseText);

})

I've been caught by this too. Means we have to parse the response HTML to detect the actual result success/fail status.

@Liam When I make a change to any content on the page that the random webapp is on, then it will display a different webapp item on the frontend of the site and get stuck on that particular item. I refresh the page many,many times and never loads a different/random item. This is strange behavior.