#1757 constrained image height to width in saved pages, but extremely wide images still look squashed in the editor itself.

One of the features of content zones is the ability to remap a URL outside the /docs/ path of the wiki. So, /en-US/docs/Mozilla/Apps (& everything under it) apparently moves to /en-US/Apps.

There's a problem, though: In the database, all these pages still live under Mozilla/Apps. The move to /en-US/Apps is just a hacky trick at the model / Django middleware level. This has caused subtle and gross problems for various other bits of the wiki.

Somehow, this needs to be resolved such that wiki pages don't just pretend to live outside the /docs/ URLspace - but actually do live there.

During the redesign, I felt rushed and so didn't do this in what I thought was the "right" way. And the "right" way to me seemed to go something like this:

• Elevate the wiki views from /docs/ to /
  • Should this allow wiki pages to override any URL on the site?
    • Maybe calls for middleware that allows route resolution to fall through to other views if a corresponding wiki page is not found. (Is that a thing?)
  • Or should it go the other way round?
    • ie. Wiki pages can live at any URL not claimed by another view in urls.py?
• Move all pages that live at / now to under /docs/ in the database, so that there's no apparent change.
• Move all pages with zone remaps to the proper URLs
• Remove the zone remap feature & hacks altogether.

Any thoughts? (esp. from @jezdez & @ubernostrum as this feels like it calls for some deep Django magic)

We've got

        <input id="next" name="next" type="hidden" value="/en-US/"/>
        <input required="required" type="hidden" name="assertion" id="id_assertion" />

twice. This causes validator errors because the IDs "next" and "id_assertion" are used twice.

redesign and profile_subscription need to go away

Quoting Les:

see if zeus is really working for us and if not, what can we improve

We are a special snowflake in our usage of django-browserid, due to historical issues of user migration from multiple auth systems and features that didn't exist in django-browserid originally.

Simplify our usage of django-browserid and remove the special cases.

I made some changes to an article recently and on a later review noticed that the WYSIWYG editor had spread a ton of <code> tags throughout the source - I'd had an unclosed code tag at one point and corrected it but didn't notice that the editor had spread open/close tags through everything which occurred later in the DOM:

https://developer.mozilla.org/en-US/docs/HTML/Element/script$compare?to=317979&from=309843

There's a separate complaint about editors but I think the real failure was a concise way to see exactly what I'd changed rather than having to eyeball it visually. Something like a diff view would have come in very handy.

I don't know why they are even in the repo, that can be easily configured on a project level. This is cruft and makes it harder to maintain kuma.

To avoid the HTTP request for /jsi18n/build:... we should use django-statici18n

We don't use statsd or graphite any more. Remove those dependencies from the dev VM setup

In wiki-min.css there is a rule that says

.page-content td,.page-content th{
    border:solid #e0e0dc;
    border-width:0 1px 1px 0;
    padding:6px;
    text-align:left;
}

The text-align:left; should become text-align:start;, as it is making problems in rtl pages (see https://developer-new.mozilla.org/he/docs/HTML).

I don't know where to change this, so I'm posting this here.

Quoting Les:

We also need to spend some time understanding what's up with memcache. I think we're still running mostly without memcache working.

http://imgur.com/OomZFrt

Custom builds for even smaller files: This feature has been greatly refined and extended since its debut in jQuery 1.8. You can now exclude combinations of 12 different modules to create a custom version that is even smaller. A new minimal selector engine, basically a thin wrapper around the browser’s querySelectorAll API, lets you shrink the build to less than 10KB when minified and gzipped. See the README for instructions on how to create a custom build, and remember that any plugins you use will also need to stick to the subset you select.

http://blog.jquery.com/2013/04/18/jquery-2-0-released/

While following the instructions available for vagrant from here: https://github.com/mozilla/kuma/blob/master/docs/installation-vagrant.rst, I was unable to get past the vagrant provision stage.

I'm on Ubuntu 13.10 (Saucy Salamander), and this is a fresh install.

This turned out to be an issue with npm unable to install the "fibers" package, and subsequent steps failed because of this. I'm not very familiar with node or npm, but I recall that this was due to an SSL certificate error. By turning off SSL vertification in npm (npm config ssl-strict false), I was able to re-run the provision step and it worked. This is most likely an issue with npm on the vagrant box, since this is what I get when I try to install a completely unrelated package called thinkpress using npm.

info it worked if it ends with ok
verbose cli [ 'node', '/usr/bin/npm', 'install', 'thinkpress' ]
info using [email protected]
info using [email protected]
verbose config file /home/vagrant/.npmrc
verbose config file /usr/etc/npmrc
verbose config file /usr/share/npm/npmrc
verbose cache add [ 'thinkpress', null ]
silly cache add: name, spec, args [ undefined, 'thinkpress', [ 'thinkpress', null ] ]
verbose parsed url { pathname: 'thinkpress',
verbose parsed url   path: 'thinkpress',
verbose parsed url   href: 'thinkpress' }
verbose addNamed [ 'thinkpress', '' ]
verbose addNamed [ null, '' ]
silly name, range, hasData [ 'thinkpress', '', false ]
verbose raw, before any munging thinkpress
verbose url resolving [ 'https://registry.npmjs.org/', './thinkpress' ]
verbose url resolved https://registry.npmjs.org/thinkpress
http GET https://registry.npmjs.org/thinkpress
ERR! Error: failed to fetch from registry: thinkpress
ERR!     at /usr/share/npm/lib/utils/npm-registry-client/get.js:139:12
ERR!     at cb (/usr/share/npm/lib/utils/npm-registry-client/request.js:31:9)
ERR!     at Request._callback (/usr/share/npm/lib/utils/npm-registry-client/request.js:136:18)
ERR!     at Request.callback (/usr/lib/nodejs/request/main.js:119:22)
ERR!     at Request.<anonymous> (/usr/lib/nodejs/request/main.js:212:58)
ERR!     at Request.emit (events.js:88:20)
ERR!     at ClientRequest.<anonymous> (/usr/lib/nodejs/request/main.js:412:12)
ERR!     at ClientRequest.emit (events.js:67:17)
ERR!     at HTTPParser.onIncoming (http.js:1261:11)
ERR!     at HTTPParser.onHeadersComplete (http.js:102:31)
ERR! You may report this log at:
ERR!     <http://bugs.debian.org/npm>
ERR! or use
ERR!     reportbug --attach /home/vagrant/src/puppet/manifests/npm-debug.log npm
ERR! 
ERR! System Linux 3.2.0-23-generic
ERR! command "node" "/usr/bin/npm" "install" "thinkpress"
ERR! cwd /home/vagrant/src/puppet/manifests
ERR! node -v v0.6.12
ERR! npm -v 1.1.4
ERR! message failed to fetch from registry: thinkpress

I understand that this is bad practice, and I shouldn't have to disable SSL verification when installing packages from anywhere.

I'm wondering if any of you have run into a similar issue? If this is reproducible for other users, I'm happy to submit an update to the installation document.

For example, do not use #content #profile .links li if #profile li would suffice.

Stylus makes over-specificity easy with the nesting feature. Nested selectors look visually appealing, and make the code more readable, but with each nest the specificity increases. We should only nest when we need the specificity it provides.

We could probably use https://github.com/educreations/django-mysql-fuzzycount/ for reducing the amount of time we spend asking the database for counts. Should make exists() calls faster, too.

https://bugzilla.mozilla.org/show_bug.cgi?id=942439

Get rid of extra calls to mdn-min.css and wiki-min.css

https://github.com/dotless-de/vagrant-vbguest

That makes sure that independent of our version of the guest extensions inside our packaged box we can be certain that users always will use the correct version of the guest extensions.

The development SSL certificate expires tomorrow.

This is also a chance to generate a cert one that is valid longer than the old one (1 year) and works for for more than just developer.mozilla.org. The apache configuration has the following hosts listed as valid for development:

• developer-local.allizom.org
• developer-kumadev.mozilla.org
• developer-mdndev.mozilla.org
• developer-dev.mozilla.org
• mdn-local.mozillademos.org

Inability to execute macro inside another macro.
It sounds redundant or something you can easily avoid of using but it causes a lot of troubles and makes some setbacks in flexibility in comparison to old mindtouch.
Let's explain on a example:
i have an old macro on a page

{{ IFSummary("docshell/base/nsIGlobalHistory2.idl", "nsISupports", "Scriptable", "1.7", "This interface provides information about global history to Gecko. It was split off from " .. Interface("nsIGlobalHistory") .. " during the transition to toolkit interfaces.") }}

It can not be rewritten for kuma preserving the link to nsIGlobalHistory. So the resulting script would be:

{{ IFSummary("docshell/base/nsIGlobalHistory2.idl", "nsISupports", "Scriptable", "1.7", "This interface provides information about global history to Gecko. It was split off from nsIGlobalHistory during the transition to toolkit interfaces.") }}

Another example:

{{ note("This interface replaces and deprecates " .. interface("nsIGlobalHistory") .. ".") }}

It could be rewritten in something like this:

So it seems to me those are legitimate reasons to enhance existing macro system a little bit.
The downsides of proposed changes are probably some "performance setbacks". I am pretty sure it is possible to avoid any security risks (after all the only executable code here are scripts(templates) that have been already approved).
But it is nothing - taking into account the flexibility of a template system achieved in result.

1. Press ctrl+N to open a new browser window, then type https://developers.google.com/speed/pagespeed/insights/?hl=en&url=https%3A%2F%2Fdeveloper.mozilla.org in the address bar and press enter
2. Click the link "show how to fix" under Enable compression.
3. See that all the svg-files that is served on MDN is not compressed/gziped

the svg-files served to MDN should be compressed/gziped for better performance

http://identity.mozilla.com/post/27122712140/new-feature-adding-your-websites-name-and-logo-to-the

We need to upgrade django-browserid before doing this.

See jazzband/django-waffle#100

Before we started using django-south for database migrations, we used schematic. Schematic is a fairly dumb system that just runs SQL and seems to break more easily than South. We don't really use it anymore, and we should just remove it from the project entirely

We have some mighty old Python dependencies.

Maybe we need something like Gemnasium to help keep us in line?

git submodule update --init --recursive

...
fatal: reference is not a tree: b8ac1085778ebed65a5c6d2af6dda4eff82bb66f
Unable to checkout 'b8ac1085778ebed65a5c6d2af6dda4eff82bb66f' in submodule path 'src/django'
Failed to recurse into submodule path 'vendor'

Seems to be related to some restructuring in the upstream django repo.

Kumascript and all its dependencies are version locked to node v0.6.12

node v0.6.12 is several years old now, and v0.12.x is around the corner. API changes will probably break kumascript as-is, if node is simply upgraded.

This situation should be remedied.

We need a way to run an elasticsearch reindex that doesn't take out the primary prod index in the process.

One approach is to maintain two indexes: One stays active, while the other is inactive & available for reindex. Once a reindex has been completed, swap the active index for the one that was just reindexed.

See #1908

Quoting David:

We're loading like a dozen JS files, we should figure out a way to manage those dependencies.

This was introduced in a247a31

God, this is super annoying and is so confusion me. Imagine how it looks to new contributors.

and write a periodic celery task for it

See https://bugzilla.mozilla.org/show_bug.cgi?id=922732 for more info

I recently updated the profile page and profile edit page to use FontAwesome for icons. If the old icons are not used anywhere else, I should get rid of them as well.

Remove:

• profile_subscription
• redesign_beta_notice
• external_signup
• elasticsearch

On the homepage I'm seeing a bunch of seemingly useless MySQL queries:

2013-12-21 20:00:01,865 DEBUG (0.000) SELECT DISTINCT `taggit_tag`.`id`, `taggit_tag`.`name`, `taggit_tag`.`slug` FROM `taggit_tag` INNER JOIN `taggit_taggeditem` ON (`taggit_tag`.`id` = `taggit_taggeditem`.`tag_id`) WHERE (`taggit_taggeditem`.`object_id` = 2  AND `taggit_taggeditem`.`content_type_id` = 51 ); args=(2, 51)

Currently, with a fresh database the redesign flag is disabled (or when only enabled for superusers). The main.js file requires the persona-login class to be used which is only available with the redesign. That way you can't login into the admin with Persona to enable the flag.

This needs quick fixing to be able to login in properly again in a non-logged in state.