Hey everyone, here is the second beta of Blocs for Mac V5.2.7.
More fixes and improvements on the way!
Have fun testing.
1 Like
Hi @PeteSharp,
In response to your question in the V5.2.7 b1 topic, It’s still exported as you see below, when the bric is placed inside the WP Post loop. And it is still the same in v5.2.7 B2.
<div class="remove-on-export text-center" data-meta-key="" data-nopaging="true" data-posts-per-page="5">
<span style="padding: 1px 5px;color:white;background-color: #3896E8;">WP Stuff</span>
</div>
1 Like
Are the other php issues fixed?
Hi @Norm,
Unfortunately they aren’t. Did you see the posts in the v5.2.7b1 topic.
Summary of issues remaining on v5.2.7b2, when bric with PHP code is placed in a Wordpress loop:
Versions 5.2.7 b1 and B2, now correctly exports the <bric-php-snippet> ... </bric-php-snippet> to Wordpress theme. as <?php ... ?>, when placed within the query loop.
Certain PHP code character combinations are being changed on preview and or export, also if the PHP code comes from the custom-bric.js, as follows:
any of these strings: '->' or '-\>' or '->' will result in this: '->'
also any of these: "'item'=>'value'," or '\'item\'\=\>;\'value\',' or ‘'item'=>;'value',’ will result in this: 'item'=>'value'
Outside of the WP Loop it exports correctly as: '->' and '=>'
Also, when the following code is placed in the wordpress loop, this is the result:
if code is <?php ?> it exports as <bric-php-snippet></bric-php-snippet>
if code is or <!--<?php ?>--> it exports as <!--<bric-php-snippet></bric-php-snippet>-->
Blocs shortcodes such as %isPreview%, when used in the html of a custom bric and the bric is added within the post query loop, it is exported literally as: %isPreview%.
A bric placed in the WP loop with this code in the html area:
<div class="remove-on-export display-in-blocs-edit-mode-only text-center" custom-bric-id-target="true" data-meta-key="" data-nopaging="true" data-posts-per-page="5">
<span style="padding: 1px 5px;color:white;background-color: #3896E8;">My String Here</span>
</div>
Will export as:
<div class="remove-on-export d-none text-center" custom-bric-id-target="true" data-meta-key="" data-nopaging="true" data-posts-per-page="5">
<span style="padding: 1px 5px;color:white;background-color: #3896E8;">My String Here</span>
</div>
And this code:
<div class="remove-on-export text-center" custom-bric-id-target="true" data-meta-key="" data-nopaging="true" data-posts-per-page="5">
<span style="padding: 1px 5px;color:white;background-color: #3896E8;">My String Here</span>
</div>
Will export as:
<div class="remove-on-export text-center" custom-bric-id-target="true" data-meta-key="" data-nopaging="true" data-posts-per-page="5">
<span style="padding: 1px 5px;color:white;background-color: #3896E8;">My String Here</span>
</div>
So, when exported, display-in-blocs-edit-mode-only is working correctly but remove-on-export is not.
Lastly, for the same scenario of the same bric, when placed within a Wordpress loop. Although it now correctly exports the <bric-php-snippet></bric-php-snippet> to Wordpress theme. as <?php ?> . However, in preview mode the tags remain literal. So in preview the php code within tags <bric-php-snippet></bric-php-snippet> injected by the custom-bric.js into the html area of the bric is visible, as the tags are unchanged in preview mode and remain: <bric-php-snippet></bric-php-snippet>
Also filing a bug report
1 Like
Ok thanks, I’ll take another look, if you could send me a php code sample I can test with your code.
Btw preview mode doesn’t generate php code for Wordpress, previews run outside of a Wordpress install so you would need to run some code on an actual Wordpress install.
Just did a quick test again and this works fine for me in a wp post loop (in both preview and export) I’m also not having any php issues with build 2. Maybe I’m missing a little detail or something specific in your set up. If you send me a copy of your Bric I’ll look at the code and place it in a loop of my own.
Can you also confirm you have build 2, its noted on the splash screen. Just incase you redownloaded build 1 unintentionally.
Hi @Norm,
I’m definitely using B2.
I will send you some brics to test. I will get it done this afternoon and DM you as soon as done.
Thanks again
1 Like
Hi @Norm,
I tested Beta2 again and here are the results, my previous report was not accurate for B2:
If the PHP code is surrounded by <bric-php-snippet> ... </bric-php-snippet> then:
- any of these strings:
'->','=>,'are exported correctly.
If the PHP code is surrounded by <?php ... ?> then:
- the PHP delimeters above are exported as:
<?php ... ?>?> - this string:
'->'is exported as'--->' - this string:
'=>'is exported correctly.
If the PHP code is surrounded by \<\?php ... \?\> then:
- the PHP delimeters above are exported correctly as:
<?php ... ?>
The %isPreview% shortcode now exports correctly either as true or false.
Also not fixed: the elements with the class remove-on-export are still fully exported and not removed.
Would you still like me to send you a test bric?
Yeah!!! even though I won’t use the beta to on my projects.
-
Fixed issue that caused Blocs to crash when dragging Brics below a video Bric.
-
Fixed issue that prevented dragging Brics above or below audio player.
1 Like
I can’t help thinking the path shown in page settings for pages should include a trailing slash when clean urls are enabled, so it appears like https://example.com/about/. After all, the full url would be something like https://example.com/about/index.html rather than https://example.com/about. The trailing slash should also be included when copying the link.
I think no trailing slash reads better, and it works. The purpose of a clean url.
But is it correct?
Search engines treat URLs with and without trailing slashes as different, so it’s important to stick to one format. Using the trailing slash ensures uniformity across your site. Then for canonicalisation, using the trailing slash prevents potential duplicate content issues if search engines were to treat the two URLs differently.
Having had various canonical issues flagged in Google search console, I’m thinking this may be the cause.
It’s interesting, just reading some discussion about it on the google forum.
The difference between a directory and a file. That makes sense. But then, with how smart google has become with identifying this stuff, the question is does it matter anymore? Bit like google doesn’t care if you have multiple h1 tags anymore. 
. Has a world of websites with no standards shifted the way it all works 
I’m going to look further into it.
1 Like
Put it this way. When I added canonical links that were coded by hand and included the end / I never received these messages from the Google search console. Google may be clever, but if we can clean something up by simply adding a trailing / I think we ought to do it.
1 Like
This post is 14 years old, but I think the take away is consistency.
There is probably a newer post somewhere 
This is newer:
Trailing Slashes in URLs: Mastering Consistency for SEO and UX | b13.
“For effective SEO, the canonical tag on a URL must match the primary URL’s structure, including using a trailing slash.”
Strangely enough I found that in three seconds using a Google search.
Saying the same thing. Likely nothing here has changed then.
Oh there is a heap of stuff on this when you search. I am just looking for stuff from the horses mouth as it were.
If you read further it indicates that for larger sites a trailing slash is better practice and removes ambiguity. In the word’s of Nike, Just Do It!
But no slash looks cooler 
I haven’t checked googles youtube channel. Lots of good stuff there, often opposing common beliefs 