If you were hiding our navigation through use of display:none and using absolute or fixed positioning to manage your custom header, then you may not have search collections visible at all. This is because when you hide components using display:none, they do not take up any space, and as such, the beginning of your page content will start much closer to top edge of the page. If you used fixed or absolute positioning in addition to display:none, your header will cover up the top of your page content and in this case, it’s the search collections.
This was an incredibly intrusive release that has essentially broken our current Open Data site as well as the State of Vermont's site without warning. We have set up cards in our Open Data site that searches based on keywords. For instance: search?tags=isothemeboundary,isothemecadastral
With this update, I cannot even browse any of our datasets...
There should have been an option to upgrade and doing so, would clone the site to test the functionality before releasing this. It has rendered our site useless and we now will likely have to spend a considerable amount of time with support fixing it.
Sorry to hear that your site is broken with the new release. The new search has been in beta since the fall and as part of the beta we've pushed folks to clone and test the new features. I'm not sure if you are listed as a site admin, but we work with marketing to send out blasts to site admins ahead of big releases as we did last week. Regardless, we've missed the mark in getting the information to you and I apologize.
In regards to your site, I'm not sure what happened but I think if you remove and add the group from your site's groups manager in the Hub admin it should resolve the issue. I added your group to a test site and some 185 items are appearing in search. Let me know if that doesn't work for some reason.
We just pushed a fix out for this on the backend. Your items should be showing up now: http://anropendata-vtanr.opendata.arcgis.com/search
For the tagging issue with your category cards, there appears to be a bug for inclusive queries. We are working on a fix and will let you know when it is resolved.
The tagging bug should be resolved. Your category cards now all seem to be directing fine, apart from the administrative boundaries card. Replacing the query in the card with http://anropendata-vtanr.opendata.arcgis.com/search?tags=any(isothemeboundary,isothemecadastral) should fix the issue.
Klara & Patrick,
I am an admin and a member of the early adopters and I did not get notification this release was coming. I have a feeling that if ESRI continues down this path with Open Data Hub they are going to have a lot of unhappy customers. We want to brand our websites with our content in our designs. When you bind our abilities to customize our websites (they are ours we pay for them), you prevent us from being able to comply with our web standards, our branding, our presence that we are building and presenting to the public. I understand that you all want to make it better for those who cannot program HTML and CSS but at what cost to the rest of us? Leave our .navbar's alone, and let us control our own sites and it would be really nice if you limited your z-indexs to something we can hide with our own code. currently the spyglass on the search is over 900.
Thank you for your input. I'm sorry you didn't get advanced warning. We do try as much as possible to post all upcoming features to our blog. Would you be willing to share where you go for updates and what would be your preferred medium to receive them?
We do understand the need to be able to brand your own Hub, which is why we allow space for a custom header, support CSS/HTML on the homepage, and have a theme builder that applies the theme across the whole app. We try to take up as little real estate as possible on the homepage by only controlling the navigation bar that contains search, notifications and sign in. We are reworking that to make it more minimal, but we're also trying to make it a better Hub experience for collaborators and visitors. For example, a visitor who enters a Hub from Google and lands someplace that is not necessarily the homepage should know who authored the content that they are viewing and find a consistent way to explore other initiatives and content. Our goal is to add more customization to these components (navigation, search collections, etc) and hopefully, this will encourage people not to hide our navigation outright, as doing so can detract from the overall usefulness of Hub.
ArcGIS Hub isn't strictly a website builder (although that is a very popular part of our app); it is a management framework for organizations to collaborate with partners and communities around initiatives relevant to their work through GIS content. This includes publishing content through websites and pages both internally and externally, but also engaging with community participants through events, surveys, and teams. There are many views in our app that currently do not support layout customization, including the search navigation bar, search results, dataset and item detail pages, event registration pages, and profiles. While we apply the theme from the theme builder and a custom header, if present, the reason we do not allow CSS on these views is to limit the likelihood we will break your site when we release new features.
We used to give everyone access to global CSS for the whole app when we were just Open Data, but unfortunately, people would absolute position all kinds of page functionality to get custom layouts. If our app were the equivalent of a static website, this might have been okay, but since we release bug fixes and feature updates nearly every week, we'd often break sites who had customized their layouts too heavily. Obviously, they would not be terribly happy with us because they'd have to adjust their CSS to compensate. With a couple thousand customers, we simply could not predict how people would be using CSS, and therefore, we'd be stuck because we couldn't release anything new without risk of affecting someone's global CSS implementation. This is why, in our app today, you have free rein over anything you want to do in your homepage with CSS, but we save just a tiny slice of the page as a safe zone to add new functionality so that we won't break your layout.
And as was the purpose of my original post, if you had hacked our safe zone (we understand, it happens) and were experiencing oddities as related to your custom header, we wanted to provide some tips that could help you troubleshoot faster in fixing your custom code.