-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upstream updates #49
Upstream updates #49
Conversation
…in-site-351 Add setting to specify admin site URL. Closes codeforamerica#351
The plugins work fine locally using nested require() calls. However, when using the requirejs optimizer, the plugins were concatenated in the main application script, whereas Google Maps API is loaded asynchronously. This led to errors in production because the local concatenated plugins were executing before their dependencies loaded. Having the plugins inline isn't ideal, but based on research it appears to be the approach with the least overhead and disruption of the existing site structure. It allows: - Guaranteed execution of the plugins after the Google Maps APIs have loaded. - Exposure of the module initialization method to the outside. With a nested require() call inside the module, the init method was not accessible outside the module scope. As inline plugins the init method is accessible again and can be used to specify where and when the module is initialized. - Removal of vendor scripts and the associated path settings in the requirejs.yml config file. Alternatives to this setup that could be investigated in the future: (a) The Promises based approach shown here http://stackoverflow.com/questions/12648598/amd-version-of-google-maps-v3-for-use-with-require-js/ The consequences of this approach are the introduction of a jQuery dependency for the loading and possible non-support for Promises in IE being an issue. (b) Include directive. See http://stackoverflow.com/questions/19337293/requirejs-optimiser-include-nested-dependencies-for-certain-files-and-folders The plugins could still be nested like how they were set up and worked locally and then explicitly included in the build. However, this may still cause them to load before the maps, so that would need to be investigated on a staging server. Other cleanup and adjustments: - Adds findNestedDependencies flag to requirejs config. Nested require calls were not being included in the optimizer. - Removes erroneous reference to term-popup-manager which is removed. - Makes bitmask return boolean for isOn method, instead of actual bit numerical value. - General code cleanup and documentation added.
Filter specs are consistently failing on Travis. This disables them till they are re-worked.
This replaces all the complicated view, JS, and controller code with 2 simple text fields for searching by location and agency name. This is a familiar interface and keep things simple and maintainable. Anything that would be built on top of this simple foundation should be based on user feedback. Note that the text fields are not styled in this commit.
…-update Map feature update
…specs Disables filter specs
This makes it easier for contributors to submit updates while retaining their own customizations in their own settings.yml
Intermittently, the clear filters test will fail. It’s most likely due to the spec checking the input field before it has actually been cleared. Hopefully 2 seconds will do the trick. We can increase if it still fails on Travis.
This also allows the text to be customized via the I18n locales.
In the previous implementation, changing the text in the locale would not update the text when refreshing the browser page, even with caching disabled. In this better implementation, the view calls the locale file and sends the text via the data attribute to the JS, which works perfectly. I also bumped the wait time for that one spec that fails intermittently on Travis
@anselmbradford, I pushed the latest changes to staging. Looks fine to me. Check it out and let me know. On my small screen, I can see how people might not know to click on "Update search results" after checking a checkbox. Would it be possible to use regular JS to make the act of checking a checkbox submit the form? If not, I think we should bring back the alert, but just for the checkboxes. |
Thanks, I'll take a look! Adding the alert back would be the quickest, since the code is already in place for it. |
Adds floating alert with button to refresh search results when checkbox filters are checked.
Added alert back. IE needs some help, will keep you posted. |
If I add a change to |
I'm able to flush memcashier via the command in customization readme, but I don't have access to ohanapi to flush/update the |
Caching is turned off in staging. Flushing MemCachier won't do anything. This is an asset precompilation issue. If you make a change to an asset, and you want to test the change on Heroku, you will need to precompile the assets locally and commit. In your |
Removes precompiled assets during browser testing so polyfills can be more easily tested.
Geolocation button was showing up when geolocation was not supported (IE8). This hides the button by default and displays it only when geolocation is supported.
Moves geolocation button on inside location filter input field above the input field. Fixes issue noted in codeforamerica#503. This makes it so when the geolocation button is hidden initially the layout doesn’t change when the geolocation button shows up.
Pushed some updates: Also, hides the geolocation box by default and moves it above the location search input (per codeforamerica#503) so that the layout doesn't shift when the geolocation button appears: There's a 1 pixel discrepancy in the geolocation button position between Chrome/FF, but it's hardly noticeable and I think this PR can proceed without resolving it. |
@monfresh Check're done from my end. Checked in IE8, IE9, IE10, IE11 on sauce labs, iOS Safari Mobile on the iOS Simulator, and Chrome, FF, and Opera locally. Please notify Edwin that there's a significant UI update we'd like to push live before pushing live. Thanks! |
Awesome! Thanks! I'll let Edwin know now. |
- Adds error type to geolocation button alert so that when that when an information alert is shown, the geolocation error alert isn’t displayed in the informational alert styles. - Updates assets.
@monfresh Just added a minor update. When clicking the checkbox filters and the alert was shown in the informational alert styling. If the geolocation button was then clicked without dismissing the existing alert and it displayed its own alert, they would appear in the last alert styles shown. 98295de makes it so the geolocation alert will always use the "Error" alert styles. |
- Removes unneeded console.log() message used in browser testing. - Updates precompiled assets.
@monfresh pushed one more. There was a |
Work in progress.
Pull in latest code from ohana-web-search while preserving SMC customizations.
Things to check:
Things to add:
Things to fix:
Note:
application.yml
is up to date. I suggest copying and pasting fromapplication.example.yml
.RAILS_ENV=production rake assets:precompile