Re: [Wikitech-l] Shifting from PHP mailer to Swift Mailer
Hi, We have prepared the PS on shifting from PEAR to SwiftMailer. Please go through and review the PS here ( https://gerrit.wikimedia.org/r/#/c/135290/ ). As the commit message says - there are some compatibility issues like :- * Couldn't find an alternative for the 'IDHost' in SwiftMailer SMTP parameters * Safemode check when $wgSMTP is unset is removed. Dont think that is necessary when using SwiftMailer * $wgAdditionalMailParams is not sent to SwiftMailer when $wgSMTP is unset, which doesn't sound needed according to http://swiftmailer.org/docs/sending.html#the-mail-transport Anyway, I could test the code successfully with Gmail SMTP settings and no SMTP settings. Thanks, Tony Thomas http://tttwrites.in FOSS@Amrita http://foss.amrita.ac.in *where there is a wifi, there is a way* On Fri, May 2, 2014 at 7:20 PM, Tony Thomas 01tonytho...@gmail.com wrote: Hello Andre, I was indeed in search of more input whether it's a good idea or bad one. Nemo tells me it will be a nice move to shift from the conventional usermailer [1]. Since its an additional task in my proposal, I am ready to take up the shifting job, as it needs to be done first, should it be done. If anyone would like to take up the job, I would be happy to pair with them too. Some discussions:- [1] : https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Third-party_components [2] : https://www.mediawiki.org/wiki/Talk:VERP#Swift_Mailer_and_VERP__40928 Thanks, Tony Thomas http://tttwrites.in FOSS@Amrita http://foss.amrita.ac.in *where there is a wifi,there is a way* On Fri, May 2, 2014 at 2:34 AM, Andre Klapper aklap...@wikimedia.orgwrote: Hi Tony, could you clarify your intention for this email? Are you seeking for more input whether it's a good idea, or if this actually needed? Or are you searching for agreement as you plan to work on a patch yourself? Or are you looking for somebody to work on this? It's not entirely clear to me from your email. Thanks, andre On Tue, 2014-04-29 at 21:28 +0530, Tony Thomas wrote: Hi, Looks like there isn't any more reply about this proposal on shifting from UserMailer to Swift-Mailer. Since, we have already started with implementing VERP, it's high time this enhancement needs to be applied, if it needs to be. If Swift-Mailer is to be done, VERP needs to be implemented as a plugin to it, or else as an additional script in the UserMailer code. Bugzilla ticket:- https://bugzilla.wikimedia.org/show_bug.cgi?id=63483 Thanks, Tony Thomas http://tttwrites.in FOSS@Amrita http://foss.amrita.ac.in *where there is a wifi,there is a way* On Fri, Apr 4, 2014 at 10:45 PM, Tony Thomas 01tonytho...@gmail.com wrote: Hi, While working on implementing VERP for Mediawiki[1], Nemo pointed to me, Tyler' recommendation[2] on shifting from PHP mailer to Swift Mailer[3]. Quoting Tyler's words : 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. My mentors too think about it to be a nice idea, and Nemo recommended adding it to my GSoC project deliverable here ( https://www.mediawiki.org/wiki/VERP#Deliverables ). But, we need more community-consensus on the same as this needs to be done first, and VERP as a plugin to it, if Swift mailer needs to be done. I have opened a BZ ticket for the same ( https://bugzilla.wikimedia.org/show_bug.cgi?id=63483). Please comment to this thread or in the BZ regarding the shift as it needs to be done for a start. The discussions we had on this till date is here: https://www.mediawiki.org/wiki/Talk:VERP#Swift_Mailer_and_VERP__40928 . [1]: https://www.mediawiki.org/wiki/VERP [2]: https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Third-party_components [3]: http://swiftmailer.org/ Thanks, Tony Thomas http://tttwrites.in FOSS@Amrita http://foss.amrita.ac.in *where there is a wifi,there is a way* ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/
[Wikitech-l] Friday RfC discussion: extension registration
This Friday we're discussing Kunal Mehta's Extension registration RfC. (This is a change from Wednesday, the usual day.) https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-05-30 https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration It'll be 1900 UTC http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140530T1900 this Friday 30 May, in #wikimedia-office. 8pm in London 3pm in Washington, DC noon in San Francisco Sorry for the change in time. The next week's chat, about Pau Giner's CSS grid proposal, will probably on Monday June 2, at a time better for Asia Australia. -- Sumana Harihareswara Senior Technical Writer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
On Sun, 25 May 2014 00:11:28 +0200, Daniel Friesen dan...@nadir-seen-fire.com wrote: However $wgValidSkins isn't something should become case insensitive, attempting that for array keys is asking for bugs. Same for putting non lowercase keys in the database and trying to make them case insensitive. The easiest way to make useskin=, $wgDefaultSkin, and $wgSkipSkins case insensitive is to normalize all skin keys from them to lowercase (which is actually only a few lines in Skin.php) and then as a breaking change say we're forbidding non-lowercase keys to $wgValidSkins (which should be rather simple since I haven't seen a single skin yet doing that which would actually be broken by such a change). Hmm. Yeah, this actually sounds very sensible. Let's make it so. To summarize: * 'skin file name' (='skin directory name' and 'skin repository name'): * pretty (that is, usually CamelCased, unless the skin name would for some reason be lowercase) * may not contain non-ASCII characters * 'skin name': * a lowercase version of 'skin file name', which would also provide any future skin loading/installation/management mechanism with a simple way to map the file/directory/repository name to the 'skin name' * user inputs (useskin, $wgDefaultSkin) are accepted with any capitalization and normalized to lowercase The requirements above are technically breaking changes, but are very unlikely to actually break anything. Right? -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] What should be the recommended / supported way to do skins? (A proposal.)
A skin has (or imho should have) (only) two name like properties:
1) Internal identifier (id):
- Used for processing at the application level and as public API
(configuration variables, url parameters, API properties, database values,
dynamically constructed page names such as for site and user scripts,
preference keys)
- Lowercase
- No non-ASCII characters
- No spaces
- Not localised
- Change this would be a breaking change
2) Display title (skin name):
- Typically starts with an uppercase letter, may contain spaces (e.g. Cologne
Blue)
- Used for graphical user interface (e.g. anywhere HTML is displayed, whenever
it is used inside an message)
- Defined by msg key skinnname-{skin}
— Krinkle
On 25 May 2014, at 18:02, Bartosz Dziewoński matma@gmail.com wrote:
On Sun, 25 May 2014 00:11:28 +0200, Daniel Friesen
dan...@nadir-seen-fire.com wrote:
However $wgValidSkins isn't
something should become case insensitive, attempting that for array keys
is asking for bugs. Same for putting non lowercase keys in the database
and trying to make them case insensitive.
The easiest way to make useskin=, $wgDefaultSkin, and $wgSkipSkins case
insensitive is to normalize all skin keys from them to lowercase (which
is actually only a few lines in Skin.php) and then as a breaking
change say we're forbidding non-lowercase keys to $wgValidSkins (which
should be rather simple since I haven't seen a single skin yet doing
that which would actually be broken by such a change).
Hmm. Yeah, this actually sounds very sensible. Let's make it so.
To summarize:
* 'skin file name' (='skin directory name' and 'skin repository name'):
* pretty (that is, usually CamelCased, unless the skin name would
for some reason be lowercase)
* may not contain non-ASCII characters
* 'skin name':
* a lowercase version of 'skin file name', which would also provide
any future skin loading/installation/management mechanism with a
simple way to map the file/directory/repository name to the 'skin
name'
* user inputs (useskin, $wgDefaultSkin) are accepted with any
capitalization and normalized to lowercase
The requirements above are technically breaking changes, but are very
unlikely to actually break anything.
Right?
--
Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Skin directory layout explanation (was: What should be the recommended / supported way to do skins? (A proposal.))
On 2014-05-20, 2:25 PM, Bartosz Dziewoński wrote:
* $IP/skins/SkinName/ for both assets and PHP files
($IP/skins/skinname/SkinName.php etc.), using require_once in
LocalSettings like extensions to load the skin, manually adding an
entry to $wgValidSkinNames in the main PHP file. This seems to be the
preferred method among modern skins, for example Erudite [3] or
Nimbus [4].
We've been discussing $IP/skins/skinname/skinname.php vs.
$IP/skins/SkinName/SkinName.php for awhile, but it occurs to me now –
after reading this patchset[1] – that it's possible some people in the
discussion may actually not know or have a misunderstanding of what this
file is.
$IP/skins/vector/vector.php or $IP/skins/Vector/Vector.php (whichever we
go with) is NOT what is currently at $IP/skins/Vector.php.
$IP/skins/Vector.php (and the like) contain classes like SkinVector and
VectorTemplate.
The proposed $IP/skins/vector/vector.php and $IP/skins/Vector/Vector.php
are meta(?) files – like an extension's $IP/extensions/{name}/{name}.php
file – which are responsible for setting things like the skin's credits,
autoloading, i18n, resourceloader modules, and registering the skin
inside $wgValidSkinNames.
For example my tutorial[1] describes 3 files in the skin structure:
* skins/myskin/myskin.php – The new skin file containing definitions
for credits, $wgValidSkinNames, $wgAutoloadClasses, $
wgExtensionMessagesFiles, and $wgResourceModules.
* skins/myskin/MySkin.skin.php – The file containing SkinMySkin and
MySkinTemplate classes. The naming came from the FooBar.hooks.php
pattern some extensions use but can be anything you want.
* skins/myskin/MySkin.i18n.php – The old i18n for the skin (from the
pre-json era of i18n). Likewise the name can be anything you want.
[1] https://gerrit.wikimedia.org/r/#/c/135384/
[2]
https://www.mediawiki.org/wiki/Manual:Skinning/Tutorial#Creating_the_skin
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Bugzilla Weekly Report
MediaWiki Bugzilla Report for May 19, 2014 - May 26, 2014 Status changes this week Reports changed/set to UNCONFIRMED: 4 Reports changed/set to NEW: 17 Reports changed/set to ASSIGNED : 45 Reports changed/set to REOPENED : 9 Reports changed/set to PATCH_TO_RE: 98 Reports changed/set to RESOLVED : 205 Reports changed/set to VERIFIED : 9 Total reports still open : 14739 Total bugs still open : 8887 Total non-lowest prio. bugs still open: 8634 Total enhancements still open : 5852 Reports created this week: 291 Resolutions for the week: Reports marked FIXED : 145 Reports marked DUPLICATE : 18 Reports marked INVALID : 12 Reports marked WORKSFORME: 16 Reports marked WONTFIX : 14 Specific Product/Component Resolutions User Metrics Created reports per component MediaWiki extensions WikidataRepo 24 VisualEditor Editing Tools 17 Wikipedia App Generic 15 VisualEditor General 10 VisualEditor MediaWiki integration 9 Created reports per product MediaWiki extensions 116 VisualEditor 46 MediaWiki 40 Wikimedia 20 Wikipedia App 19 Top 5 bug report closers jforrester [AT] wikimedia.org 32 jrobson [AT] wikimedia.org18 bawolff+wn [AT] gmail.com 17 hashar [AT] free.fr 10 aklapper [AT] wikimedia.org 8 Most urgent open issues Product | Component | BugID | Priority | LastChange | Assignee | Summary -- MediaWiki | Database | 63677 | Highest | 2014-05-18 | wikibugs-l[AT]lists. | Update script is failing midway due t MediaWiki | Database | 32551 | Highest | 2014-05-25 | gdubuc[AT]wikimedia. | Descriptionless files (Missing page_l MediaWiki | General/Unkno | 65665 | Highest | 2014-05-25 | bjorsch[AT]wikimedia | Revisions missing from mediawiki.org. MediaWiki ext | Diff | 58274 | Highest | 2014-05-16 | wikibugs-l[AT]lists. | Implement an order-aware MapDiffer MediaWiki ext | OAuth | 57336 | Highest | 2014-05-25 | wikibugs-l[AT]lists. | Make metawiki the central OAuth wiki MediaWiki ext | Translate | 65738 | Highest | 2014-05-25 | niklas.laxstrom[AT]g | Fix styling issues for Special:PageMi MediaWiki ext | WikidataRepo | 52385 | Highest | 2014-05-13 | wikidata-bugs[AT]lis | Query by one property and one value ( MediaWiki ext | WikidataRepo | 64956 | Highest | 2014-05-20 | wikidata-bugs[AT]lis | Install Entity Suggester on the Wikid MediaWiki ext | WikidataRepo | 64600 | Highest | 2014-05-22 | wikidata-bugs[AT]lis | write script that touches every item MediaWiki ext | WikidataRepo | 63224 | Highest | 2014-05-23 | wikidata-bugs[AT]lis | review backend part of entity suggest Pywikibot | General | 63605 | Highest | 2014-04-09 | devunt[AT]gmail.com | Ignore expired cookie VisualEditor | ContentEditab | 65642 | Highest | 2014-05-24 | esanders[AT]wikimedi | VisualEditor: SurfaceWidget always cr ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
