Please join us on google hangout June 11 @ 1900 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=WikiFont&iso=20140…>
for the following Tech Talk:
*How, What, Why of WikiFont*
*Presented by Core Features Engineer: Shahyar Ghobadpour, Visual Designer:
May Galloway and Mobile Apps Engineer: Monte Hurd*
*Wikifont-glyphs is a collection of icons that have been used in our
projects, made into a font. We will be showcasing how you can take
advantage of this icon font set, how to request for more icons and
contribute to the set. *
If you want to watch live you can join the hangout here
<https://plus.google.com/events/chpgv8usjd6dn38on07njjk28hg> and follow
along and ask questions in #wikimedia-office on IRC.
More info about Wikifont here
<https://www.mediawiki.org/wiki/Design/Wikifont>
The WebFont Tech Talk will also be available for viewing later here
<https://www.youtube.com/user/watchmediawiki> on the mediawiki youtube
channel.
Thanks!
Rachel
One thing that concerns me about the proposed composer setup, that I
haven't mentioned yet, is the nesting of the project hierarchy, with
mediawiki/core/vendor inside mediawiki/core.
You know that we have mediawiki/extensions instead of
mediawiki/core/extensions -- that makes it easy to check out all
Gerrit repos in the natural directory hierarchy and to still have a
clean $IP/extensions which you can use for installer testing or whatever.
I wonder if a similar solution is possible with vendor -- could we
have mediawiki/vendor instead of mediawiki/core/vendor? Then it would
be possible to play around with dropping things into $IP/vendor while
still having the "vendor" git repo checked out in a sensible location,
available for editing.
-- Tim Starling
On Tuesday, June 10, 2014, Federico Leva (Nemo) <nemowiki(a)gmail.com> wrote:
> Yes, there are docs. Please edit and link from other pages.
> https://www.mediawiki.org/wiki/Google_Hangout_meetings
Interesting, I didn't know about this page.
Tech Talks use Google Hangout on Air, which is a slightly different kind of
beast. Our process is documented at
https://www.mediawiki.org/wiki/Project:Calendar/How_to_schedule_an_event
and the page welcomes edits.
The video can be watched from the Google+ URL that we are advertising. If
for whatever reason you prefer to watch it in YouTube, that page also
contains a link to the corresponding YouTube page, under "Links". If it
makes sense, I would prefer to avoid sending two different URLs in our
announcements pointing to the same video.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
This will diverge from the original discussion so I'll start a new thread.
On 2014-06-11, 9:22 PM, Tim Starling wrote:
> In other news, I found a serious security vulnerability in SwiftMailer
> and have reported it upstream.
On 2014-06-11, 10:55 PM, Tim Starling wrote:
> Swift, by contrast, is a 43 KLOC monolith which does all three things
> and a kitchen sink of other bits and pieces, like its own dependency
> injection system (Swift_DependencyContainer) supported by a custom
> autoloader.
> Maybe we should think about installing PEAR Mail in the vendor
> directory using Composer, instead of Swift.
If you don't like Swift Mailer's code, I did bring it up during the RFC,
but Swift Mailer isn't the only well maintained mailer library.
Besides Swift Mailer there is also PHPMailer:
https://github.com/PHPMailer/PHPMailer
Which seems to be the mailer WordPress uses. They say Drupal uses it
though I'm unsure of what Drupal's default is because of their
convoluted plugin structure (just attempting to hunt down the URL to
clone Drupal core's git repo from was hard enough, even the second time
around).
I let things move on with Swift after Parent5446's comment on the subject:
> This is not comprehensive, but Swift_Mailer seems to be a **lot** more
> robust. PHPMailer has everything packed into a few classes, whereas
> Swift_Mailer actually has a separation of concerns, with classes for
> attachments, transport types, etc. A result of this is that PHPMailer
> has two different functions for embedding multimedia:
> addEmbeddedImage() for files and addStringEmbeddedImage() for strings.
> Another example is that PHPMailer supports only two bodies for
> multipart messages, whereas Swift_Mailer will add in as many bodies as
> you tell it to since a body is wrapped in its own object. In addition,
> PHPMailer only really supports SMTP, whereas Swift_Mailer has an
> extensible transport architecture, and multiple transport providers.
> (And there's also plugins, and monolog integration, etc.) Parent5446
> 22:56, 7 March 2014 (UTC)
--
https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Third-party_compon…
Which doing a bit of digging myself appears to be partially incorrect.
Looking at the code PHPMailer does support mail() and sendmail in
addition to SMTP. So it basically supports the exact same list of email
sending methods as Swift Mailer's transports do.
So if you don't like the kitchen sink that Swift was picked for
PHPMailer is something else to review before falling back on PEAR
libraries, even with composer.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
In the current discussion about git submodules vs. composer there are
several different underlying assumptions about the user's situation. I think
it would help the discussion to clarify which use cases we are dealing with.
Here is an attempt:
1) Shared hosting without shell. The user uploads code with (s)ftp, and
can't install anything globally.
2) Shared hosting with non-root shell and git installed. The user can use
git directly on the server, but can't install anything globally without
root. They can manually download composer to their home directory.
3) Root on a (virtual) server. The user can install packages, and do any of
the above.
The git submodules vs. composer discussion seems to focus on case 2). Case
1) could be addressed by providing a 'bundle' tar file with all dependencies
that can be uploaded via (s)ftp. In case 2) composer or git can be used on
the server to fetch dependencies separately.
When using git, it might be worth considering Parsoid's method of making the
core repository a submodule of a 'core-deploy' repository which has all
dependencies, rather than making the dependencies a submodule of core. This
avoids issues with git complaining about dirty submodules in the common case
of updating core often.
In case 3) the user has a full packaging system at their disposal, which
means that it is theoretically possible to set up a fully-featured MediaWiki
system with a few commands. So far we don't have any special support for
this case (we expect users to follow the manual tarball setup), which made
sense in the past as folks running their own server were fairly rare.
Many of our users are starting to take advantage of cheap virtual machines
though, which are now widely available at a price point comparable to shared
hosting. For this reason I think that we should put more effort into
supporting case 3), for example by providing good Debian packaging which
lets you do "apt-get install mediawiki-full" and get a MediaWiki install
with caching, VisualEditor and so on. There are also other benefits here
beyond the initial install, like automatic security updates with
unattended-upgrades.
So far we don't have a good idea of how common the different use cases are,
and how this distribution is changing. I think that we should try to get
this information so that we can have a more informed debate.
Gabriel
The Flow team is going to work in a few weeks on automatically archiving
talk pages, so that we can enable Flow on pages where there are already
existing conversations. Basically, this means moving the old discussions on
an archive page, and leaving a link for "See archived talk page" visible on
the new Flow board.
That means there'll be a minute where a currently active discussion would
get interrupted, and have to be restarted on the new Flow board. That will
be a pain, but it would only be a one-time inconvenience during that
transition moment.
The team's goal for LiquidThreads transition is essentially the same --
turning the existing conversations into a form that we can archive, and
preserve for the future. If we tried to turn ongoing LQT discussions into
ongoing Flow discussions, we'd actually be spending more development time
on archiving the deprecated feature than we would spend on archiving wiki
talk pages.
There's a few more big features for Flow that we're working on this summer;
we'll have some new things to show off pretty soon.
Danny
Hi,
using polipo http proxy which works fine with wikipedia as long as
the machine is online.
For offline usage, polipo has the option to store cached http data
persistently on disk - and something perhaps style sheet related
goes wrong when trying to do this with wikipedia and firefox.
The polipo version I am using is this:
http://www.pps.univ-paris-diderot.fr/~jch/software/files/polipo/polipo-1.1.…http://www.pps.univ-paris-diderot.fr/~jch/software/files/polipo/polipo-1.1.…
Testing with http://en.wikipedia.org/wiki/Sanskrit :
* connect network, logout from WP, set firefox proxy, load wikipedia page - works fine
* now configure polipo as "offline"
(eg /usr/bin/curl -m 5 -d 'proxyOffline=true' 'http://127.0.0.1:8123/polipo/config?' )
* clear firefox cache
* reload page - content is loaded but looks like css is not applied at all.
Watching the load process with web-console/network does not show any obvious
problems. All GET requests succeed and appear to return sensible data from
the polipo cache, also 2 css requests.
Only the CentralAutoLogin request fails which is probably expected and should
be irrelevant for css?
Does anyone have an idea what goes wrong here?
Richard
---
Name and OpenPGP keys available from pgp key servers
Hello,
Please feel free to join the Engineering Community Team (ECT) tomorrow
(June 10th) at 1700 UTC in #wikimedia-office on IRC. The ECT hosts office
hours in #wikimedia-office the second Tuesday of every month.
Check here <https://www.mediawiki.org/wiki/Project:Calendar> for upcoming
summer Wikimedia tech events & meetings! This page is regularly updated
with new events.
Thanks!
Rachel