Hi,
> In short, using Parsoid directly for visual editing is an unsupported
> configuration, and is likely to stop working altogether in the foreseeable
> future.
> for current work in progress). The early prototype already sets up
> MediaWiki, VisualEditor, RESTBase, Parsoid, Math, as well as
Hi,
> Travis-CI is only currently used by a very small number of repositories,
> luckily.
I'm not sure I understand the underlying connotation in your comment
but some non-core developers are happy about Travis-CI [0] and how it
allows them to run a test environment independent from WMF (and/or
Hi,
order to have other features work). This is a risky path for the open
source MediaWiki though, as sooner or later I expect some announcement
that MW will only work on HHVM, which would be a pity.
An interesting thought that may not be appreciated or shared by all
third-party users or
the management
of dependencies in itself is reinvented.
[0] https://github.com/wikimedia/mediawiki/blob/master/composer.json#L45
Cheers
On 2/15/15, Daniel Friesen dan...@nadir-seen-fire.com wrote:
On 2015-02-14 11:30 PM, James HK wrote:
Hi,
Extensions/plugins are not libraries.
Frankly I want to give
Hi,
Extensions/plugins are not libraries.
Frankly I want to give whoever built the addition to Composer that
allows packages to install as WordPress plugins and MediaWiki extensions
a good kick.
Thanks for your elaborated inside but somehow this doesn't tell the whole story.
Take for
While I agree that the most important cases should be *really* easy, I
worry about the implication that all other cases (including development of
core MediaWiki without using VMs) should necessarily be allowed to be
*really* complex.
If I'm no longer able to run MediaWiki from a XAMPP
don't have to manually do much.
My biggest worry is the small installation on a server where the maintainer
doesn't have full admin/root access -- shared departmental web servers or
shared-PHP hosting services.
-- brion
On Wed, Jan 28, 2015 at 11:16 AM, James HK jamesin.hongkon
Hi,
- Get rid of wikitext on the server-side.
- HTML storage only. Remove MWParser from the codebase. All
extensions that hook into wikitext (so, almost all of them?) will need
to
be re-written.
You gotta to be kidding. It seems we are a bit out of sync here with
the
Hi,
On 1/21/15, Daniel Friesen dan...@nadir-seen-fire.com wrote:
On 2015-01-20 12:21 PM, James HK wrote:
Hi,
- Get rid of wikitext on the server-side.
- HTML storage only. Remove MWParser from the codebase. All
extensions that hook into wikitext (so, almost all of them
Hi,
== Changes since 1.24.0-rc.2 ==
* The composer.json file has been renamed to composer.json.sample after
Jamie Thingelstad reported that his composer.json was overwritten by
the tarball.
I had the same issue not aware that MW has replaced my existing
composer.json and by the time I
Hi,
[Putting purely the mw dev hat on]
I'm putting a hat on from pure observer point of view as neither a
member of de.wp nor wmf.
So dont complain that mw fixes a bug in how page protection. If you are
I'm not complaining, I'm observing the events that happened around the
introduction of
Hi,
It could mean that, but of course it is actually introduced to prevent
the German community from deactivating the Media Viewer.
User JEissfeldt, removed `mw.config.set(wgMediaViewerOnClick,
false);` from Common.js [0] and is the same person who sets
`protect-level-superprotect`.
I have no
Hi,
etc. These are important capabilities of the wiki that have been used
for many clearly beneficial purposes. In the long run, we will want to
apply a code review process to these changes as with any other
deployed code, but for now the system works as it is and we have no
intent to remove
Hi,
I just went on to `git pull --rebase origin master` on getting MW
1.24 master and suddenly I see a Whoops! The default skin for your
wiki ($wgDefaultSkin), vector, is not available.
I have to say that I'm not really interested in modifying the
LocalSettings.php just to get a MW working as
a bit and keep thing on a non-personal
level? I'd appreciate it.
On 7 August 2014 18:18, John phoenixoverr...@gmail.com wrote:
Exactly what I warned about. Yet another example of poor
thinking/execution
and exactly what I predicted.
On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkon
To make things worse, I noticed on my development environment that our
own scap-equivalent will just go on to run composer update even if the
file conflicted. This causes it to remove the extensions and libraries
we currently install via composer, also breaking the site.
I hope for the sake
What kind of decoupling did you have in mind?
Not specifying that each skin has to have exactly one lc identifier
and then starting to rely on this requirement and generate all sorts
of secondary names, identifiers, paths, class names, etc. from that.
E.g why not just ask that skin for it's
That is just the unfortunate truth. We are
not going to misuse libraries and hack together MediaWiki just so extension
installation can be *slightly* easier.
This sort of behaviour towards non-WMF extension developers is
interesting and if your objective is to alienate (as with the attitude
18 matches
Mail list logo
