Merge Issues - (Getting Sass and JS changes merged with Master)

@sujato, @blake,

I started a new thread to deal with the process of getting my changes merged back in with master.

I started the process of merging master into my working branch and have run into a surprisingly large number of conflicts. My bad, but I just did not realize that Master was so active.

Anyway, it will be quite a process I think and so wanted to start a new thread to deal with the issues that come up.

First issue and an important one is I would ask that commits to master involving Sass files be frozen until this process is done. Some of the files are so different, that merging by hand is the only way to go at this point. If there is a hot fix that absolutely must go into master, let me know and I can cherry pick it into my code.


No worries, consider sass frozen at my end.


I attempted to do a rebase to bring in the changes from master, but this was unsuccessful. I was able to merge master into the branch (painstakingly), but can no longer run the server.

@blake, can you advise please? Here is what I see when attempting to invoke the server:

bash-3.2$ invoke server
Running the server…
Traceback (most recent call last):
File “/Users/davestrandberg/.pyenv/versions/suttacentral/bin/cherryd”, line 110, in
options.pidfile, options.imports, options.cgi)
File “/Users/davestrandberg/.pyenv/versions/suttacentral/bin/cherryd”, line 17, in start
exec(“import %s” % i)
File “”, line 1, in
File “/Users/davestrandberg/eLanceDev/suttacentral/sc/”, line 9, in
from sc import app, updater
File “/Users/davestrandberg/eLanceDev/suttacentral/sc/”, line 6, in
from sc import config, logger, root
File “/Users/davestrandberg/eLanceDev/suttacentral/sc/”, line 6, in
from sc import show, donations
File “/Users/davestrandberg/eLanceDev/suttacentral/sc/”, line 10, in
import sc.donations
File “/Users/davestrandberg/eLanceDev/suttacentral/sc/”, line 1, in
import stripe
ImportError: No module named 'stripe’


Oh yeah, from time to time we add python dependencies. If you get the ‘no module…’ message just run pip install -r requirements.txt before running invoke server.

For future reference I’ve updated the code so when there is an import error running invoke server, the error message includes the advice to run pip install -r requirements.txt to fix it.


Hi guys,

I have merged the code and attempted to deploy to staging using some directions that Blake had provided a while back.

It looks like it worked, but will need to verify shortly.

Personal update: Chaos around here for the last 4 days. We moved into a new house which is less than a mile away (good), but just an hour after the movers left, with our entire house in dissarray, our son severely broke his arm (skateboarding down a slide - yes, very, very, foolish!). Up all night, no beds, and then surgery in the morning and then more sleepless nights to follow. Fun, fun, fun. I am back in the saddle now though.

I plan on testing on staging and fixing known issues (eg the drop down search). Let me know any other issues you see or are aware of.


1 Like

Found one minor issue unrelated to the Sass stuff. It looks like the link to the donations page is hard wired and will take you off of staging. No biggie I suppose, but just figure you should be aware while browsing staging it is easy to not realize you ventured off the staging server:

Visit our donations page

Fantastic, thanks so much. I’ve let our team know of this so now they can all check it out. We can also test it on various mobiles; I’ve got a Galaxy Nexus, so I’ll try that.

I hope your son is okay. It is excellent that he does stupid things now: if you don’t do them when you’re a kid, when can you do them? If you need any personal time, that’s fine, just let us know.

@blake has also added a new feature to the sidebar, which integrates information from discourse for the relevant sutta. It shouldn’t affect your work, but I thought you might want to check it out.

Hopefully we can switch this to the main site in a few days.

So for @Moneycito and @blake, here are some bugs that have come to light. From @Vimala:

One think I don’t like so much is in the sidebar under Navigation tab, the next and previous suttas appear under each other (at least on the screen I’m looking at now: 1280x1024 on Chrome in W8). I would prefer them next to each other, taking up less space - I think it should be possible. But just my preference. They used to be next to each other (on the same screen) so you probably had a good reason to change this.

This isn’t a change, it’s a bug. I see the same thing on my screen. The added “Discuss & Discover” tab must do something that creates this.

On Galaxy Mini: looks much better but cannot find the sidebar menu at all. search does not work and the top menu gets printed over the bottom bar so becomes unworkable (at least for “sutta” and “abhidhamma” but not for “vinaya”???). So still some work to do there if you want the mobile version to work. But I must say this is a very old android 2.2.1 phone.

On my Galaxy Nexus, it works well. The animations are jerky, but this is par for the course on a somewhat older phone (even the Google apps are kind of jerky). But they work just as they’re supposed to.

I’m seeing the same bug in the sidebar prev/next links. In addition, I’m seeing a similar bug with the script selector buttons under the “Control” tab; the last button is pushed on to the next line. This is not the case on my laptop.

Then there’s a weird bug with the prev/next links at the bottom of the page (not the sidebar ones). They are oddly inflated, and the round background is distorted. (see screenshot)

In addition to all these, there is an old bug, one that I had secretly hoped would be fixed by redoing the header, but alas not. And that is that the width of the text column in the text pages is too narrow, squashing into about the left 70% of the screen, which also means the text is too small. Screenshots are attached.

This one shows that the horizontal spacing issue also affects the footer. It also shows the previously mentioned bug with the text prev/next links.

I also had a brief chance to test the site on an iPhone, not sure of the model, but anyway not the latest.

There was a very serious bug, the header aggressively disappeared behind the browser header. It was next to impossible to use it at all. As a general rule, I prefer to keep our code simple, clean, and standards-compliant. So in edge cases like this, rather than resorting to complicated hacks to get it working, sometimes its better to just disable the header animations completely for that model. But it’s your call.

A more minor bug on the same phone, the Notification arrow broke, I guess the relevant CSS properties were not supported. Use an image instead, or don’t worry about it?

Thanks for the testing. I am going to push some more code that does NOT address any of the issues mentioned, but rather is an attempt to get a workable solution for the search drop down.

This turns out to be very difficult to implement in the exact same way as before given the new requirements of the header. In particular, to get the search drop down to be the exact same width as the search input box is not possible (or will require a major refactor which might then cause us to lose the nice flow of the width of the search input box). I can give more details if interested in reasons, etc.

To address this, I have taken some liberty to move the search results popup below the header and add a shadowbox. The width will be “to fit” with a max. value of 90%. This gives a net result this is similar to the way the other menus work. I am very biased of course, but I actually prefer the new look and there are fewer instances of work wrap, etc. Hopefully this will work for everyone.

My first push of this code to staging might not work, so I will send out another message when it is usable.

Finally, I will get to the issues that cropped up in testing tomorrow. Some of them I know the cause and we can get a work-around (eg the next prev buttons having a ‘distorted’ background). Some of the issues with the side bar I assume Blake will look into if they have to do with the new feature that was added. I have multiple iPhones and an iPad available for testing here.


Okay, cheers.

FYI I have got the “nasty space-creating bug” back on staging now, it was gone yesterday.

OK, the staging sausage is cooked and you can test out the search drop down.

I was able to use the technique that @blake had mentioned a while back to use “more javascript” to get the width of the drop down to be the same (or larger, if need be) as the input box.


Thanks, I’ve checked it out. it’s getting there. Certainly “more javascript” is, on the whole, a way of making everything better :neutral_face:

But the autocomplete still doesn’t feel like part of the search. I seems like it’s on a different plane, a lower z-axis. The menus when they expand are at the same z-height as the header, but the autocomplete isn’t. Not saying it’s literally at a different z-index, just how it appears. The menus solve this by simply extending a bit of whitespace. If we really wanted to emulate their look and feel, we’d make the entire box in which the search input field is contained turn white (i.e. the <li>), and extend the white to connect with the autocomplete, which would have a min-width of the <li>.

The simplest way to get the connection would simply be to change the height from 40px to 30px. But it’s not that great.

See how the search works here on Discourse: the box includes the input and the results, you clearly see these are part of the same thing.


I can fix all of the bugs listed above by @sujato if you like. I just assumed you might want to take care of the side panel issues that were mentioned (next / prev buttons on top of one another, etc.).

Let me know what you prefer.


I actually tried a number of things like that and the result simply did not look right. I will play with it a bit more and see if I can get a style that brings the pieces together as you suggest in a visually appealing way.

Thanks for being so responsive (no pun intended) in your comments. Quick feedback is rare and appreciated!


Okay I looked into the sidebar problem. The problem was that float: left had been replaced with ‘display: inline-block’ in the sidebar. I designed the sidebar, and it was made deliberately and consistently using a float layout, IIRC the reason being that only with float could I get 50% + 50% to equal 100%.
See also this answer on stackexchange:

We could use inline-block, but to achieve a pixel-perfect layout we’d have to remove all the spaces between the buttons, and that’d make the HTML code fugly. Using float is the lesser of two evils here. Most of the site HTML/CSS was made by @sujato, and he can be a bit inconsistent in using different layout strategies at near random to make it look right. The sidebar happened to have been designed by me and it uses float by design.

edit: I’ve pushed the fix to the branch.

I resent the use of the phrase “near random”. Please use the correct form, “completely random”.

Yes, layouts can be tricky. The header actually uses two layout techniques to get things right, including the floating method you mention. There is an overall liquid layout consisting of a fixed pixel left column and then a flexible, 100% percentage based, right column. Getting the right column to be 100% is a bit tricky but can be done. Once you have that, you can divide it into % chunks and use a negative margin if you want to compensate for any weirdness with border widths.

The key with trying to get <a> and <span> type tags to use % widths properly in this kind of a layout is to to stuff them into a linked list or a <div> and then center them within the <li> and <div> which are able to handle the % width properly.

This should be fixed now on staging

This bug should be fixed now on staging. In addition, a similar issue that prevent header text from centering on small screens was fixed.