Change Details

Currently, when VE is initialized, it will load HTML from a REST endpoint. In production, it would do this by hitting the `/rest_v1/page/html/{title}` andpoint, with `redirect=false&stash=true`, which is backed by RESTbase. This will fail if the backend is configured to not use RESTbase, because the submitted etag will not match. @matmarex suggested in T320531#8313224 > There are a few ways to fix this: > > Set wmgVisualEditorAccessRestbaseDirectly = false [...], so that the client-side request is replaced by a server-side request (easiest fix for now, and we use this config on private production wikis; however it'd be better not to use this for public production wikis, since it makes the editor slower to load) > > Make that URL be served by MediaWiki, not RESTBase (I don't know how to go about that) > > Set $wgVisualEditorFullRestbaseURL to a different URL prefix that is served by MediaWiki and contains compatible APIs (I don't know if such URL prefix actually exists now) Perhaps even simpler, we can just ignore the $wgVisualEditorFullRestbaseURL setting when in direct mode.

The VisualEditor API can use two backends to access parsoid: DirectParsoidClient, or VCSParsoidClient, which talks to RESTbase. When we switch VE on a wiki from using RESTbase to direct mode, edit sessions that started out using RESTbase as the backend need to continue using RESTbase, so they don't lose access to the stashed base state, which would cause the edit to fail. To achieve this, the VE API needs to detect which backend the client had originally been loading data from, e.g. using a cookie or by inspeciting the etag submitted in the request body. == original Description == Currently, when VE is initialized, it will load HTML from a REST endpoint. In production, it would do this by hitting the `/rest_v1/page/html/{title}` andpoint, with `redirect=false&stash=true`, which is backed by RESTbase. This will fail if the backend is configured to not use RESTbase, because the submitted etag will not match. @matmarex suggested in T320531#8313224 > There are a few ways to fix this: > > Set wmgVisualEditorAccessRestbaseDirectly = false [...], so that the client-side request is replaced by a server-side request (easiest fix for now, and we use this config on private production wikis; however it'd be better not to use this for public production wikis, since it makes the editor slower to load) > > Make that URL be served by MediaWiki, not RESTBase (I don't know how to go about that) > > Set $wgVisualEditorFullRestbaseURL to a different URL prefix that is served by MediaWiki and contains compatible APIs (I don't know if such URL prefix actually exists now) Perhaps even simpler, we can just ignore the $wgVisualEditorFullRestbaseURL setting when in direct mode.

The VisualEditor API can use two backends to access parsoid: DirectParsoidClient, or VCSParsoidClient, which talks to RESTbase. When we switch VE on a wiki from using RESTbase to direct mode, edit sessions that started out using RESTbase as the backend need to continue using RESTbase, so they don't lose access to the stashed base state, which would cause the edit to fail. To achieve this, the VE API needs to detect which backend the client had originally been loading data from, e.g. using a cookie or by inspeciting the etag submitted in the request body. == original Description == Currently, when VE is initialized, it will load HTML from a REST endpoint. In production, it would do this by hitting the `/rest_v1/page/html/{title}` andpoint, with `redirect=false&stash=true`, which is backed by RESTbase. This will fail if the backend is configured to not use RESTbase, because the submitted etag will not match. @matmarex suggested in T320531#8313224 > There are a few ways to fix this: > > Set wmgVisualEditorAccessRestbaseDirectly = false [...], so that the client-side request is replaced by a server-side request (easiest fix for now, and we use this config on private production wikis; however it'd be better not to use this for public production wikis, since it makes the editor slower to load) > > Make that URL be served by MediaWiki, not RESTBase (I don't know how to go about that) > > Set $wgVisualEditorFullRestbaseURL to a different URL prefix that is served by MediaWiki and contains compatible APIs (I don't know if such URL prefix actually exists now) Perhaps even simpler, we can just ignore the $wgVisualEditorFullRestbaseURL setting when in direct mode.