Skip to content
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

Sites: Gap/space missing between sites for every 3rd site #5

Closed
alisterscott opened this issue Nov 17, 2015 · 0 comments · Fixed by #1082
Closed

Sites: Gap/space missing between sites for every 3rd site #5

alisterscott opened this issue Nov 17, 2015 · 0 comments · Fixed by #1082

Comments

@alisterscott
Copy link
Contributor

When viewing wordpress.com/sites on a mobile device (or a narrow screen size), the gap/space between every third site is missing.

sites_no_gap_mobile

Expect to see the same space/gap between every site.

@rralian rralian added this to the Core: Iteration 17 milestone Nov 30, 2015
@gwwar gwwar self-assigned this Dec 1, 2015
sirreal pushed a commit that referenced this issue Dec 5, 2018
sirreal pushed a commit that referenced this issue Dec 5, 2018
sirreal pushed a commit that referenced this issue Dec 6, 2018
…1-1-0

Bump interpolate-components to 1.1.0
sirreal pushed a commit that referenced this issue Dec 6, 2018
sirreal pushed a commit that referenced this issue Dec 7, 2018
…1-1-0

Bump interpolate-components to 1.1.0
sirreal pushed a commit that referenced this issue Dec 7, 2018
…1-1-0

Bump interpolate-components to 1.1.0
sirreal pushed a commit that referenced this issue Dec 11, 2018
…1-1-0

Bump interpolate-components to 1.1.0
sirreal pushed a commit that referenced this issue Dec 11, 2018
sirreal pushed a commit that referenced this issue Dec 11, 2018
…1-1-0

Bump interpolate-components to 1.1.0
sirreal added a commit that referenced this issue Nov 14, 2019
* first commit

* copy files from wp-calypso

* Run script + setup test harness

* Make index.js a binary

* add travis config and tweak README

* add section to readme explaining how to add new tests

* prettify + remove all references to config

* add tests: merge-lodash-imports

* tests: add modular-lodash-no-more

* tests: add combine-reducer-with-persistence

* tests: add combine-state-utils-imports

* tests: add i18n-mixin-to-localize

* tests: add modular-lodash-requires-no-more

* i18n-mixin-to-localize: must use dbl quotes

* bump package for release

* Fix build for npm

* should be able to run from anywhere

* fix broken deps so tests can pass. do not use yarn

* no yarn

* add single tree rendering

* Update dependencies to latests versions (#4)

* Update dependencies to latests versions

Updated deps, hopefully to get rid of GitHub's security warnings about `hoek`.
The update also updated `package.json` to NPM 6 format.

* Tell Travis CI to use Node 10

* Fix codemod name in documentation (#5)

* Merge pull request #8 from Automattic/add/remove-create-reducer

Add codemod to remove create-reducer

* Prep for calypso

* npm install
sgomes pushed a commit that referenced this issue Jan 29, 2020
Fix TypeError on string body 'error' from rest-proxy
sgomes pushed a commit that referenced this issue Jan 29, 2020
* Fix: Stop treating completely failed network requests as successes

Resolves #5

When certain network requests fail because the internet connection is completely broken they are coming through as if they were successes and the passed callback is called with `(err = null, data = {})`. This breaks the application logic which depends on failing requests actually failing.

I added the strict-equality check on the returned `statusCode` because I noticed that when the network connection was severed it was coming back with a value of `0` and not `null`. This appears to fix the problem I'm observing.

On the other hand, it's not clear to me when the status would be `null` or why this check is in there to begin with. I'm not sure what other things could be breaking as a result of this change. Would really appreciate some review and some insight into this odd behavior.

Thanks!

* Only accept 2XX status codes as successful requests

* pkg: bump to 4.0.0-alpha.1 version

* Bump package version to v4.0.1
sgomes pushed a commit that referenced this issue Feb 18, 2020
Fix TypeError on string body 'error' from rest-proxy
sgomes pushed a commit that referenced this issue Feb 18, 2020
* Fix: Stop treating completely failed network requests as successes

Resolves #5

When certain network requests fail because the internet connection is completely broken they are coming through as if they were successes and the passed callback is called with `(err = null, data = {})`. This breaks the application logic which depends on failing requests actually failing.

I added the strict-equality check on the returned `statusCode` because I noticed that when the network connection was severed it was coming back with a value of `0` and not `null`. This appears to fix the problem I'm observing.

On the other hand, it's not clear to me when the status would be `null` or why this check is in there to begin with. I'm not sure what other things could be breaking as a result of this change. Would really appreciate some review and some insight into this odd behavior.

Thanks!

* Only accept 2XX status codes as successful requests

* pkg: bump to 4.0.0-alpha.1 version

* Bump package version to v4.0.1
becdetat added a commit that referenced this issue Jan 20, 2021
becdetat added a commit that referenced this issue Jan 20, 2021
* Add show on hover cap. to info popover

* Bump CI

* Bump CI #2

* Change popover timeout to 250ms

* Bump CI #3

* Bump CI #4

* Bump CI #5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants