Navigate to URL

I’m facing some problems when navigating in my pages with some browsers.
My site (www.lucabenanti.com) is still to be finished, but, anyway it mainly has one PHOTO page with 5 argument photo blocs and one GRAPHICS page.
NAVIGATE TO PAGE functions works fine, so the graphics page is fine.
NAVIGATE TO URL seems to have some problems (particularly with FIREFOX) in reaching the appropriate bloc link.

First time I open the browser, it’s difficult to reach the appropriate bloc.
After first time, CHROME and SAFARI work fine (usually), FIREFOX seems to be always in trouble.
For example, if a write to anyone saying … -please go to http://www.lucabenanti.com/photo/#galleriaasso-, this often goes fine in CHROME and SAFARI (not always in SAFARI, to be honest), never in FIREFOX.

Is there anyone able to explain me where I’m wrong ?

Thanks in advance

You have a hyphen at the end on the url. Remove that and it should work fine. (your ID doesn’t have one)

Thanks for your suggestion, Malachiman.
Unfortunately, the hyphen you’re referring to is just used in the example I mentioned.
The ‘normal’ bloc URL is http://www.lucabenanti.com/photo/#galleriaasso

Thx anyway

1 Like

I would add some more infos about this problem.

There are some cases where NAVIGATE TO URL function simply doesn’t work !

Having a look to my HOME page (www.lucabenanti.com) you can easily see I created 6 images, with a title and a brief speech.
I’m used to add interaction details on the images on HOME page, then pointing to the bloc present on the PHOTO page.

  • CASE 1 - - - -
    Interaction details (usually) work fine on CHROME and SAFARI (they easily work better on chrome rather than on safari, but I would not to like to look for a needle in a haystack…).
    Anyway, it’s a matter of fact there must be an error in my ‘coding’, because these damned internal links don’t anyway work on FIREFOX and other browsers such as OPERA.
    At least first time you click on the internal links.

  • CASE 2 - - - -
    There’s another situation where nothing work on every browser …
    If I add a ‘particle’ bric on, just as an example, any title beneath one of the 6 images (with interaction details ‘fulfilled’) the result is that neither the NAVIGATE TO URL nor PARTICLE bric work.

On any browser !

Anybody able to understand where I’m wrong ?

Thx in advance, guys

@lgeb I think you have to use ID’s to create the section bookmark along with the HTML page name prefix… So for example, if you name a section (Bloc) ID galleriaasso or let’s say we just want to got to a Bloc ID’ with the name bloc-3, then your URL link would look like:

http://www.lucabenanti.com/photo/index.html#galleriaasso
OR http://www.lucabenanti.com/photo/index.html#bloc-3

Another example: If you choose to output to clean url’s then you have to add the subdirectory that the index.html is in plus add index.html as a suffix BEFORE the #ID

If you addd this url to your link http://www.lucabenanti.com/photo/index.html#asso then it should go to the relevant bookmark.

@Hypnoman I tried to apply the suggestions you’re hereby reporting, but no way, as you can see.
Don’t understand why it’s working fine on CHROME and SAFARI and no way on the other browsers.
On the other way round, I cannot suggest to just use those browsers as well …

Thanks Darren, I appreciated

@lgeb if it was my site then I would first run a performance report and fix all those recommendations that matter: https://gtmetrix.com/reports/www.lucabenanti.com/Rxsj0EvU

Check out the Waterfall tab in the results - it highlights why your site is slow to load.

Then I would (persona preference) get rid of the www suffix and have a non-www site. After that I’d add SSL (I use Letsencrypt as it is free and sufficient for most of my sites - I use WHM/CPANEL)

But first of all I’d try loading my site without using the preloader in Blocs. I’m not suggesting that’s the issue. It’s just that your site is soooo slow to load, I would troubleshoot a few things. And lastly I would consider make sure I have the right hosting (I never used cheap shared) for my requirements.

As I was saying at the really beginning of this post, this site is still under improvement; it’s only a first version, with some problems to be surely fixed.

Thanks for your investigations.
The site is the outcome from BLOCS, and, it will surely be ‘soooo’ slow on Chrome/Safari, but it simply doesn’t work on some other browsers.

I’m firstly trying to have it just running, solving performance matters you underlined later on.

Thanks

Have you tried removing the www part of the link in the URL. Most browsers will just use the http or https.

This url works for me on Chrome, Safari, Firefox:

lucabenanti.com/photo/index.html#natura

Albeit it is very slow to load, and the pre-loader remains for 20+ seconds for me. I would tackle the image optimisation and SSL first (IMHO).

@hendon52 @hypnoman. Yes, the SSL part is on the way to be fixed.
Even if, I was wondering why I’m not facing problems, on any browser, if using NAVIGATE TO PAGE instead of TO URL.

I’ll anyway let you know.
I’ll keep you lined up

The reason you should check the WWW part of the url is that it was, at one time, an identifier to let people and browsers know they were connecting to a website server. This differentiated a website server from others, such as FTP or Mail. On websites, they all use the HTTP protocol, so it’s not necessary these days to use the WWW in a URL. Most browsers will automatically assume they are connecting to a web server with just the HTTP designator, or even without it altogether. However, there can be an issue if someone types WWW as the designator in front of a domain name.

Most websites are contained within a PUBLIC.HTML folder on your server. However, because some people still use the WWW designator (sometimes both WWW and HTTP - such as in your URL), web hosts will usually create a redirect link that will direct web browsers to the site within the PUBLIC.HTML folder. If that redirect link is missing, or hasn’t been created by your web host, the link to your website may fail.

This could be the reason why some browsers work and some don’t. Some browsers may simply ignore the WWW bit, whilst other may use it and leave the web server to do a redirect . it’s almost like its being treated as a subdomain of your site.

In the screenshot below, you will see that the redirect link appear in the cPanel of the web host. It simply points to the main site in the PUBLIC.HTML folder. If that WWW link isn’t showing on your hosting, it may well explain why some people cannot access your site via a WWW designator. The simple answer to ensure consistency, certainly when creating URL links within your website, is to drop the WWW bit altogether. It isn’t necessary at all.

To better understand this. Just think what happens if you create a subdomain on your website named “shopping”. The URL for your subdomain would be “shopping.yoursite.com” Your domain name is essentially a subdomain of the top level domain “.com” . whereas, the word “shopping” is is a subdomain of your main domain. These elements are separated by a “.”. Therefore, if a URL is structured as “http://www.yourdomain.com”, the www bit may be viewed as a subdomain. If the subdomain doesn’t exist, then there will be no redirect - a page not found error.

@hendon52 Thanks for your suggestions.
I’m not so confident with web matters, but your wording definetely is very well detailed and helpful.
I’ll accordingly manage.
I do appreciated.
Thanks,
Luca