Ladsgroup added a comment.

  In T280247#7328671 <https://phabricator.wikimedia.org/T280247#7328671>, 
@EBernhardson wrote:
  
  > In T280247#7327314 <https://phabricator.wikimedia.org/T280247#7327314>, 
@Ladsgroup wrote:
  >
  >> I looked at the patches, a brain dump:
  >>
  >> - One rather easy way to look at it, is to move the assets (logo, etc.) to 
the deploy repo (while keeping a default in the main one), it feels weird 
changing the gui codebase for something very specific to WMF (the gui is 
heavily used outside WMF as well). We should change it to support multiple 
sites but having the docroot for both wdqs and wcqs there seems misplaced to me.
  >
  > Sure i can move it all to the deploy repo. It seemed unlikely to me that 
anyone else was using this since we had hardcoded wdqs assets in the main repo. 
It sounds like they should have never been there.
  
  I understand. The default is our production (mostly) but it's used outside 
and it's part of WMDE's standard bundled Wikibase release.
  
  >> - speaking of docroot, Can I bikeshed? where does this name come from? it 
seems very unusual to me (by not conveying much information) but it might be 
just me not knowing about standard web servers.
  >
  > In apache httpd the DocumentRoot (shorthand docroot) is the root directory 
assets are served out of. In this implementation the rewriting forms a 
conceptually layered document root, where first we reference the global assets 
and then the site-specific assets. Nginx shortened this to just `root` in it's 
configuration(maybe? I don't really know the provenance). Basically at some 
point in the past (perhaps less so today? book ngrams for docroot peak in 2011) 
docroot was synonmous with "where the web server looks for files".  Could call 
it `sites` or something else if it aligns more with peoples understanding.
  
  Ack. Thanks for explanation
  
  >> - I suggest splitting the puppet patch to 1- Refactor 2- adding wcqs. That 
way we can get the first part in and make sure nothing in wmde-side is broken
  >> - The traffic patch needs an LVS patch on top (maybe the third puppet 
patch?)
  >> - It might be me very conservative but maybe for start can we have the 
files in docroot hard-coded in puppet? There are not many of them and wildcard 
apache redirects seem scary to me but not a big deal. Just a suggestion. Feel 
free to ignore.
  >
  > We can if you prefer, i went with this particular direction (global assets 
first, then fallback to site-specific assets) to reduce the uncertainty of the 
redirecting. By checking the global root first we guarantee any file in the 
main build is always accessed directly, there can't be weird overrides from 
specific sites that make it do something unexpected.  Only files that are 
completely undefined in the primary repo will pull from the site-specific 
docroot's.
  
  If you're confident that it won't break(TM), I don't mind either way.

TASK DETAIL
  https://phabricator.wikimedia.org/T280247

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: EBernhardson, Ladsgroup
Cc: Manuel, Ladsgroup, Addshore, Aklapper, Gehel, CBogen, ttaylor, Zbyszko, 
Suran38, Biggs657, Invadibot, Lalamarie69, MPhamWMF, maantietaja, Juan90264, 
Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, Kent7301, joker88john, 
CucyNoiD, Nandana, Namenlos314, Gaboe420, Giuliamocci, Cpaulf30, Lahi, Gq86, 
Af420, Bsandipan, Lucas_Werkmeister_WMDE, GoranSMilovanovic, QZanden, EBjune, 
merbst, LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Scott_WUaS, 
Jonas, Xmlizer, jkroll, Wikidata-bugs, Jdouglas, aude, Tobias1984, Manybubbles, 
Mbch331
_______________________________________________
Wikidata-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to