Google Sites 404 Error

[Maren Ruminski]

Youprobably have at least one page without whatever frontmatter defines $siteSeries (or maybe even a taxonomy or taxonomy term). You likely need to make the using of $siteSeries conditional around line 45 of partials/templates/opengraph.html.

First, instead of modifying a theme file, override it by placing a copy in the layouts directory in the root of your project. This allows you to update the theme to a newer version without losing your changes.

Second, the referenced error is not thrown when you run hugo server because of this line. The hugo.IsProduction method returns false when you run hugo server, and it returns true when you run hugo.[1] When running hugo server the opengraph template is never called.

Finally, the referenced error occurs because the opengraph template expects to find a series taxonomy if you have defined series in the front matter of any content page. To fix, add this to the root of your site configuration:

Thanks a lot again for your detailed answer.

So, if I understand correctly, I should move all the theme folder (so in my case the PaperMod folder) to /layouts/PaperMod/?

So it should be something like this (again in my case):

Chrome: This webpage is not available. The server at www.xyz.com can't be found, because DNS lookup failed. DNS is the network service that translates a website's name to its Internet address. This error is most often caused by having no connection to the internet or a misconfigured network. It can also be caused by an unresponsive DNS server or a firewall preventing Google Chrome from accesing the network.

When I log in to my facebook account I can see most things, some photos and videos dot not show though. Doing a google search results in the search results displaying but I can't access the pages linked.

If that does not help, then try changing your DNS servers temporarily to Google's (8.8.8.8 and 8.8.4.4) just to make sure that the DNS server that you are using is not having problems. To do this on windows 7:

The problem is, that if someone visits the site for the first time (or with a cleaned cache) taking a look at a dataset gives an 404 error (see below). The site in itself seems to work fine, it is the access to the data that does not work properly.

Weird is, that if you then click on the link to change the language (which in fact is a link to another site) and then back, it starts to work and the data becomes visible. You should be able to reproduce this behavior, just click on one of the categories and then choose any dataset. Once it started working, it will keep on working till the next time the cache is cleared.

This Connection is Untrusted You have asked Firefox to connect securely to your-site.staging.wpengine.com, but we can't confirm that your connection is secure. Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.

When you use WP Engine's staging service your site is mirrored on a temporary domain which is provided by WP Engine. Most likely what is going on here is that your site is requiring an SSL certificate and the one it's expecting would be for your normal domain (not 'your-site.staging.wpengine.com').

The staging site isn't for testing your SSL because you're on a staging address, where you have zero control of the SSL as it belongs to WP Engine and you have no true way to force it properly.Staging is for troubleshooting and theme development.

Your staging site works with https and being a wpengine.com subdomain there is already a valid certificate. However, by default, the staging gets created with http. If you try to access your login using https it will redirect, forcing you to login with unsecured form and yielding browser errors. Contact support and have them force staging to use https for all your future staging for this site.

I have a site RVT and a building RVT in Cloud Worksharing. I understand we have to use the "acquire coordinates workflow" to work with shared coordinates in cloud workshared models, and I have done that many times with success. Today I've imported the site.rvt into the building.rvt and acquired the site coordinates. But when I try to link the building back into the site with "Auto - By Shared Coordinates" I get the following error:

This is perplexing because 1) I've never seen this error before, and 2) of *course* shared sites in the linked file cannot be modified... Cloud Worksharing has never supported this, which is why we use "acquire coordinates", etc.

I think I've finally solved this. It appears that there is something non-default with the shared coordinate system in our project template, which gets propagated to all new projects. The fix appears to be to use the new "Reset Shared Coordinates" tool (Revit 2021) on the site model before linking it into the building model(s). Simply resetting the shared coordinates in the building models is not enough.

When I put in the connection information on the destination site (of the locally-running v7 source site), it runs for a while with the "Analysing remote site..." message displayed, then just shows the red error message "Error when comparing sites".

If there is something duplicated in the v7 site's data which I could go and resolve, I'd be happy to do that, but this message doesn't give quite enough information. Have you come across this error before or have any suggestions where the issue might lie?

This is a v7.6.3 site which I have only now started working with, for this migration. There is a lot of cruft which needs to get cleaned up, but I was hoping to push it all into v8 before dealing with the cleanup effort.

Originally, I was trying to get it directly into the existing v8 site, but then figured perhaps that was too much complexity for Converge to deal with, and set up a fresh, empty v8.14.0 site to "import" into first - then I could perhaps pull it from that temp v8 site into the final destination site.

Also, I thought it might make sense to "upgrade" the 7.6.3 site to 7.15.7 via regular Umbraco methods before attempting the Converge transfer (That was when I got the error message posted above). After I got that message, I wondered if the result would be better if I instead rolled back to the original 7.6.3 version and used the Converge API-only on that site.

Looks like it's a problem with a data type that uses the "Umbraco.UploadField" property editor - probably the "Upload" data type, unless you have created any others. Are any of the rows "ErrorMerging", highlighted in red?

TemplatesData TypesDocument TypesMedia TypesContentContent TemplatesMediaDictionary ItemsMacrosMedia FilesUpdate ReferencesDelete ContentDelete Content TemplatesDelete MediaDelete Document TypesDelete Media TypesDelete Data TypesDelete TemplatesDelete Dictionary ItemsDelete Macros

As per your recommendation, I started working with individual categories of entities. I was able to merge in all the DataTypes without issue (the resulting list is all white), but then if I compare again, leaving the "DataTypes" showing, I now see several reddish "Difference" lines in the DataTypes list. It appears to be Content and Media pickers which are now showing "Difference" (specifically it shows the "Configuration" text as different)

A spot check shows that there ARE Doctypes with that property... some more details about which Content item or specific Doctype is causing the failure would be helpful. Also, considering that the Doctypes are Equal between sites, the only thing I can figure is that at some point a certain Doctype HAD that property, then it got deleted from the DocType, but the Content still has reference to the property data in the database?

Just working on the media picker changes for 8.14.0 now. Last full test I ran was on 8.13.0. Can you copy the "Configuration" text (both remote and local) and post here. I'd be interested in seeing what the actual differences are.

For the Macros, the files should get created at the same time as they are created on the database. That looks like they can't be found during the compare. Are they "Equal" now that you've copied them manually? Does the "File Content" show when you expand one?

This is the "MVC Partial view" field in the Macro editor in the back office (or XSLT if that is populated). It is valid to leave it blank, and in my tests this has always returned an empty string, which didn't cause this problem.

For the content and media pickers, I think the start node is causing the difference. Rather than compare the StartNodeIds directly Converge looks up the path and name and compares them. This allows the guids to differ, even if they represent the same content/image.

Yep, have been testing the new release which will fix that (or at least tell you the name of the problem content). It'll also resolve the Media Picker issues for v8.14.0. Should get it out this weekend.

I had no issues installing, and it seems to be running nicely. I started it about 4 hours ago, and it's still running - the status bar and text have been updating and letting me know that everything is proceeding. It has finished the Content and is now importing the Media.

You know, it might be helpful if there was a way to export a list of the "MergeError" items... I noticed some of the media had failed to import due to filenames which are too long, or missing files, etc. These are understandable issues, which could be fixed at the "source"... so having a list of these would be really great.

I was able to get almost all of the the large v7 data imported into an empty v8.13.1 site. There were some MergeErrors - but it might be due to corruption or other issues. It's enough for my satisfaction, since we can manually check/fix those relatively few.

The next portion of the import is to get that data imported into a smaller already-existing v 8.14.0 site. Running converge from inside the existing v8 site, I was able to do the Compare, and import the "schema" items (DataTypes/Doctypes/Macros/Templates, etc.) But when I set it to import the Content and Media, it ran for quite some time, but then the progress message stopped updating - it seemed to be stuck on a single Content item for several hours. I stopped it and checked the "Content" area - I saw that some of the Content nodes were imported (they were displaying as unpublished), but not all. I tried running it again, and it got stalled on a different Content item.

3a8082e126