Gabriel Torres

Thank you for reporting this issue. I have added an internal bug report for this, so that it can be addressed for a future release

Glad to hear you've found the answer to your problem.

Thanks @Marc Stridgen! It was, in fact, the anonymity option, which I couldn't find, as in order to reach the page where it is located, one needs the user's password! 🙂
 

Thanks @Marc Stridgen! It was, in fact, the anonymity option, which I couldn't find, as in order to reach the page where it is located, one needs the user's password! 🙂
 

Of course. The setting itself is in each group (the allowance of this). You can see it on the first tab under the Privacy Settigns section. At present yours is set to "allowed". 
Then on from that, the user chooses this at an account settings level. This is found in {yourName}->Account Settings->Security and Privacy

Thank you for the report. I have added this as a bug report to be fixed in a future release

@Matt
One new suggestion:
Disallow: /discover/content-started/  

This url is already blocked in the current version robots.txt

@Stuart Silvester In our case,the reviews are only enabled in two databases in Pages: books (which lists our books) and courses (which lists our online courses). Maybe an option in Pages to select the kind of property, i.e. a setting that we can select the proper property (e.g., Book https://schema.org/Book or Product https://schema.org/Product), depending on the kind of database we have. I believe this would fix the issue. Just an idea. Because right now the platform lists everything as Article.

Just a quick update on this to let you know that a fix has been pushed for this, so it will be in a future release. I will update once that has gone in

The problem as far as I can see is with Google. Schema.org supports the aggregateRating property in an Article schema type - https://schema.org/Article (and many others).
However, Google is picky and they only support it in a certain types. - https://developers.google.com/search/docs/advanced/structured-data/review-snippet. You'll notice that they don't have support for reviewing 'Articles'.
It comes down to whether to leave it in place for any other search engine or platform that uses the data, or remove it to appease Google.

Thank you for reporting. I have added a bug report for this so that it can be looked into

I confirm links to all my articles have been reported by Google with this issue.

Hi,
After the improvement in Review microdata added in version 4.6.8, Google is now complaining about this:
Invalid object type for field "itemReviewed"
Sample URL: https://www.clubedohardware.com.br/livro-redes-de-computadores
Where:
"aggregateRating": { "@type": "AggregateRating", "reviewCount": 5, "ratingValue": 4.8, "bestRating": "5" } If you run this URL at https://search.google.com/test/rich-results, you will see the same error being pointed out.
Please advise.
Cheers.

Hello,
In the email template "Reported content notification", the following part:
{$email->language->addToStack("go_to_this_x", FALSE, array( 'sprintf' => array( mb_strtolower( $email->language->addToStack( $report::$title, FALSE ) ) ) ) )} Should be replaced with:
{$email->language->addToStack("go_to_the_report", FALSE)} Explanation:
With the default code, the button "Go to this report" that is present in the email is created based on the go_to_this_x language string. While in English this works fine, in other languages it creates two issues:
1. "this" can be either a male or a female word, depending on the noun. So we end up with a gender mismatch in this particular case.
2. In English, the word "Report" can be either a noun or a verb. However, in other languages, the noun and the verb corresponding to "report" may be different.
In summary, in Portuguese, we end up with "Ir a este Denunciar", while the correct form would be "Ir à esta denúncia".
The fix is very simple, however, as the platform already have this phrase in its correct form as go_to_the_report.
So simply replacing one key by the other solves the issue.
Thanks! 🙂

Hello,
In the email template "Reported content notification", the following part:
{$email->language->addToStack("go_to_this_x", FALSE, array( 'sprintf' => array( mb_strtolower( $email->language->addToStack( $report::$title, FALSE ) ) ) ) )} Should be replaced with:
{$email->language->addToStack("go_to_the_report", FALSE)} Explanation:
With the default code, the button "Go to this report" that is present in the email is created based on the go_to_this_x language string. While in English this works fine, in other languages it creates two issues:
1. "this" can be either a male or a female word, depending on the noun. So we end up with a gender mismatch in this particular case.
2. In English, the word "Report" can be either a noun or a verb. However, in other languages, the noun and the verb corresponding to "report" may be different.
In summary, in Portuguese, we end up with "Ir a este Denunciar", while the correct form would be "Ir à esta denúncia".
The fix is very simple, however, as the platform already have this phrase in its correct form as go_to_the_report.
So simply replacing one key by the other solves the issue.
Thanks! 🙂

Thank you for informing us of this. I have added a bug report for this for you

It's available, you just have to click on "Help" then, "Release Notes".

@Matt Following up our conversation about the excelente upcoming Robots.txt feature, the new, updated tutorial on Robots.txt is excelent, as it has several lines that we didn't have in our robots.txt. However, we ended up with a few lines that we have added in the past that we want you opinion/feedback on:
Disallow: /notifications/ Disallow: /tags/ Disallow: /checkout/ Disallow: /subscriptions/*/?do=purchase Disallow: /index.php?* Disallow: /*?app=* Disallow: /*/?do=download Disallow: /*?do=email Note: we have the tags feature disabled.
Should we keep them? Should we remove them? What is your opinion?
Thank you in advance! 🙂
 

I wrote about the robots.txt file back in 2015 but nobody wanted to listen 😛 
My topic: I advise you to remove "share by email"
Other topics:
Robots.txt request! Seo error on /?do=email Robots.txt - IP.Board 4.x IPS4 ~ robots.txt Use of robots.txt Broken links due to ?do=email&comment=47180, etc

I think if you have tags disabled, it's fine to disallow those.

Notifications, checkout, subs purchase are all fine to omit.
I'm unclear what google will index with 'index.php?*' but this is likely fine as long as you have rewritten friendly URLs on.

I'd need to audit to see what 'app=*' would disallow. Generally it should be fine but there may be some functionality that doesn't have a friendly URL.
do=download/do=email both fine to disallow. I'll tweak the robots.txt file to include some of those.

@Matt Following up our conversation about the excelente upcoming Robots.txt feature, the new, updated tutorial on Robots.txt is excelent, as it has several lines that we didn't have in our robots.txt. However, we ended up with a few lines that we have added in the past that we want you opinion/feedback on:
Disallow: /notifications/ Disallow: /tags/ Disallow: /checkout/ Disallow: /subscriptions/*/?do=purchase Disallow: /index.php?* Disallow: /*?app=* Disallow: /*/?do=download Disallow: /*?do=email Note: we have the tags feature disabled.
Should we keep them? Should we remove them? What is your opinion?
Thank you in advance! 🙂
 

@Matt Following up our conversation about the excelente upcoming Robots.txt feature, the new, updated tutorial on Robots.txt is excelent, as it has several lines that we didn't have in our robots.txt. However, we ended up with a few lines that we have added in the past that we want you opinion/feedback on:
Disallow: /notifications/ Disallow: /tags/ Disallow: /checkout/ Disallow: /subscriptions/*/?do=purchase Disallow: /index.php?* Disallow: /*?app=* Disallow: /*/?do=download Disallow: /*?do=email Note: we have the tags feature disabled.
Should we keep them? Should we remove them? What is your opinion?
Thank you in advance! 🙂
 

Thanks @Rikki! 🙂
 

Thanks @SeNioR-. BTW I simply updated our themes to use the default font, this way we don't need to load these fonts from Google in order to improve page load performance.