Gabriel Torres

Hi,
The default Display > record template from Pages has a small glitch. The <br> tags at the end should be inside the {{if}} statements, otherwise we have too much space at the bottom of the page when the {{if}} conditions aren't met.
Default:
<br> {{if $commentsAndReviews}} <a id="replies"></a> <h2 class='ipsHide'>{lang="user_feedback"}</h2> <div class='ipsResponsive_pull'> {$commentsAndReviews|raw} </div> {{endif}} <br> {{if $updateForm}} <div class='ipsAreaBackground_light ipsPad'> <h2 class='ipsType_sectionHead'>{lang="cms_front_update_fields" sprintf="$record::database()->recordWord( 1 )"}</h2> <ul class='ipsForm ipsForm_vertical'> {$updateForm|raw} </ul> </div> {{endif}} Suggested fix:
{{if $commentsAndReviews}} <br> <a id="replies"></a> <h2 class='ipsHide'>{lang="user_feedback"}</h2> <div class='ipsResponsive_pull'> {$commentsAndReviews|raw} </div> {{endif}} {{if $updateForm}} <br> <div class='ipsAreaBackground_light ipsPad'> <h2 class='ipsType_sectionHead'>{lang="cms_front_update_fields" sprintf="$record::database()->recordWord( 1 )"}</h2> <ul class='ipsForm ipsForm_vertical'> {$updateForm|raw} </ul> </div> {{endif}} Thanks.
PS: Please move this topic to the suggestions forums if this isn't considered a bug per se. Thanks.

ACP -> Pages -> Databases -> edit your database -> Topics tab -> Rebuild synchronized topic content

Done

Just an addition to the above. I had to add the following to robots.txt:
Disallow: /profile/*/reputation This addition is only necessary if you followed the same steps above and removed /profile/ from robots.txt

I have moved this to suggestions, as its more design choice than a bug as such

Hi,
I noticed today in our community, and could confirm that this is also present here at your community, that there is a comma placed after the username in topics. See it in the screenshot below:

Investigating this further, this issue is caused by the byline_itemprop language string: By %s,
This string is used whenever a date is placed in the sequence, however in this particular context, as the date is placed in a new line, and the comma looks ugly IMHO.
So, I believe the byline_nodate_itemprop language string should be the one used in the forums > front > topics > topic template, not byline_itemprop.
I don't know if this topic is a bug report or a suggestion, please move it to the suggestions forum if that is the case.
Cheers!

Hi,
I noticed today in our community, and could confirm that this is also present here at your community, that there is a comma placed after the username in topics. See it in the screenshot below:

Investigating this further, this issue is caused by the byline_itemprop language string: By %s,
This string is used whenever a date is placed in the sequence, however in this particular context, as the date is placed in a new line, and the comma looks ugly IMHO.
So, I believe the byline_nodate_itemprop language string should be the one used in the forums > front > topics > topic template, not byline_itemprop.
I don't know if this topic is a bug report or a suggestion, please move it to the suggestions forum if that is the case.
Cheers!

What's New in Version 2.2.7.1:
Fix error reported.

They have deprecated the sitemap submission endpoint l. We’re aware of it. 
More information TBA 😉 

Hello,
The sitemap task is failing to send the updated sitemap to Bing since 12/21/2021:

Please advise.
Cheers.

They are sorted by when they were created. If you would like to change this feature, please leave your suggestion in the Feature Suggestion forum. I can move this for you, if you would like?

I've just raised a bug report for this (6503). We'll get it fixed.

Having taken a look at this, I just wanted to let you know this is something that would be addressed in a larger review of validation items

Thanks for the update, I have reopened the report.

@Andy Millne Both of these keys are translated here, yet it is shown in English in the context presented in the first post. You should take a look into this, it is a bug.

@Marc Stridgen Thanks. Anxiously waiting for this implementation/fix... 🙂
 

New addition to robots.txt for the same issue:
Disallow: /*?*do=clearFilters Disallow: /*/?do=report The following Pages templates must be updated to include rel='nofollow':
Listing > filterMessage (for the do=clearFilters)
Display > record (for the do=report)

New addition to robots.txt for the same issue:
Disallow: /*?*do=clearFilters Disallow: /*/?do=report The following Pages templates must be updated to include rel='nofollow':
Listing > filterMessage (for the do=clearFilters)
Display > record (for the do=report)

Hello,
This suggestion is regarding the logo schema markup that is added at the bottom of every page.
Currently, the logo that is used is the theme's main logo. There are two issues with that, in my opinion:
1. The main logo is rectangular, whereas the logo provided by the schema markup should be squared;
2. The main logo changes with the theme. For instance, we have two themes here, a light one and a dark one, and in the dark theme, the logo has a dark backgound and different colors. This way, the logo will change depeding on the theme that is being used. If the dark theme is crawlable by Google, Google may display a different logo than intended in results.
Therefore, I think it would be better if the logo in the JSON schema markup is (1) squared and (2) fixed (not changing depending on the theme).
So, my proposal is to change the system/Output/Output.php file, from:
if( $logo = \IPS\Theme::i()->logo_front ) { $jsonLd['organization']['logo'] = array( '@type' => 'ImageObject', '@id' => \IPS\Settings::i()->base_url . '#logo', 'url' => (string) $logo ); } To:
if( $logo = json_decode( \IPS\Settings::i()->icons_homescreen, TRUE ) ) { $jsonLd['organization']['logo'] = array( '@type' => 'ImageObject', '@id' => \IPS\Settings::i()->base_url . '#logo', 'url' => \IPS\Settings::i()->base_url . 'uploads/' . $logo['original'] ); } Here I used the "homescreen" logo present in the Icons & logos page from the ACP because it fits the criteria I want (squared and fixed), but you may want to create a new setting for this specific logo.
I hope you can improve this.
Cheers!

Hello,
This suggestion is regarding the logo schema markup that is added at the bottom of every page.
Currently, the logo that is used is the theme's main logo. There are two issues with that, in my opinion:
1. The main logo is rectangular, whereas the logo provided by the schema markup should be squared;
2. The main logo changes with the theme. For instance, we have two themes here, a light one and a dark one, and in the dark theme, the logo has a dark backgound and different colors. This way, the logo will change depeding on the theme that is being used. If the dark theme is crawlable by Google, Google may display a different logo than intended in results.
Therefore, I think it would be better if the logo in the JSON schema markup is (1) squared and (2) fixed (not changing depending on the theme).
So, my proposal is to change the system/Output/Output.php file, from:
if( $logo = \IPS\Theme::i()->logo_front ) { $jsonLd['organization']['logo'] = array( '@type' => 'ImageObject', '@id' => \IPS\Settings::i()->base_url . '#logo', 'url' => (string) $logo ); } To:
if( $logo = json_decode( \IPS\Settings::i()->icons_homescreen, TRUE ) ) { $jsonLd['organization']['logo'] = array( '@type' => 'ImageObject', '@id' => \IPS\Settings::i()->base_url . '#logo', 'url' => \IPS\Settings::i()->base_url . 'uploads/' . $logo['original'] ); } Here I used the "homescreen" logo present in the Icons & logos page from the ACP because it fits the criteria I want (squared and fixed), but you may want to create a new setting for this specific logo.
I hope you can improve this.
Cheers!

@Jim M bug was caused by the plugin below. It must be removed from the Marketplace.
 

Hello,
Here in our install we found the following issue.
Because the source code adds the ?d= parameter in $table->baseUrl, navigation links also have this parameter.
For example, for our https://www.clubedohardware.com.br/noticias/armazenamento/ page, the default navigation becomes https://www.clubedohardware.com.br/noticias/armazenamento/page/2/?d=6, https://www.clubedohardware.com.br/noticias/armazenamento/page/3/?d=6 and so on, instead of just https://www.clubedohardware.com.br/noticias/armazenamento/page/2/, https://www.clubedohardware.com.br/noticias/armazenamento/page/3/ etcetera.
To fix this, I had to edit /applications/cms/modules/front/database/category.php and remove the following line:
$table->baseUrl = $table->baseUrl->setQueryString( 'd', \IPS\cms\Databases\Dispatcher::i()->databaseId ); I know we have a very customized Pages configuration here, but I am giving you a heads up to check whether this line should really exist.
Cheers!

Thank you for the report! I’ve identified the issue and a new version containing a fix will be submitted shortly. I apologize for the inconvenience and hope you haven’t lost faith in the plugin.
Edit: I’ve set the price to $1,000 to prevent anyone from installing it until the fix is released.

As I wrote in the other topic, I’ve identified the issue and will submit a new version shortly. In the meantime, please disable the plugin. You might have to manually edit some posts, so hopefully not too many posts were made.

@Jim M bug was caused by the plugin below. It must be removed from the Marketplace.