Hello All,
First time post here.
Trying to resolve a problem where I'm trying to request an RSS feed
from my WIki server to a secure tomcat web server (under my control) but
I'm getting this error:
Failed to load RSS feed from https://my.web.server.com/feed: Error
fetching URL: Peer certificate cannot be authenticated with known CA
certificates
This may be a simple fix either by importing the ssl certificate from
the server i wish to get the feed from or by maybe telling PHP to ignore
the certificate ? Not sure since I don't really know if the Wiki PHP
code is using cURL to do the request or something else. And I wouldn't
be too sure on where to import it to if i need to do this.
I tried going into the /includes/HttpFunctions.php file and setting
"protected $sslVerifyHost = false;" and "protected $sslVerifyCert =
false;" but no go.
any help would be nice.
Chris
On 27.03.2012 00:33, Tim Starling wrote:
> For the record: we've discussed this previously and I'm fine with it.
> It's a well thought-out proposal, and the only request I had was to
> ensure that the DB schema supports some similar projects that we have
> in the idea pile, like multiple parser versions.
Thanks Tim! The one important bit I'd like to hear from you is... do you think
it is feasible to get this not only implemented but also reviewed and deployed
by August?... We are on a tight schedule with Wikidata, and this functionality
is a major blocker.
I think implementing ContentHandlers for MediaWiki would have a lot of benefits
for the future, but if it's not feasible to get it in quickly, I have to think
of an alternative way to implement structured data storage.
Thanks
Daniel
To answer my own question, the whitespace was being consumed because
of the adjacent <noinclude> and <includeonly> style tags. It appears
that there are two ways you could solve this:
1) use   to get a space that isn't encoded as ' '
2) use <nowiki/> after the space so that the other tags see the
adjacent nowiki tag and not whitespace that they gobble up.
I used #1 and my template expands as expected now.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 version available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
On Mon, Mar 26, 2012 at 12:50, Maximilian Doerr <cybernet678(a)yahoo.com> wrote:
> I strongly disagree with removing wiki text. Several thousand bots depend
> on it. Especially Cluebot NG which is a highly sophisticated anti-vandalism
> bot. I recommend going our current route where the visual editor writes the
> Wikimarkup realtime and vice versa.
I suspect maybe you didn't understand Daniel's message? (or didn't
read it?) I imagine most pages will still use the same markup we have
today after his idea is implemented.
For the pages that are different, the bots can and should adapt.
-Jeremy
Hi all. I have a bold proposal (read: evil plan).
To put it briefly: I want to remove the assumption that MediaWiki pages contain
always wikitext. Instead, I propose a pluggable handler system for different
types of content, similar to what we have for file uploads. So, I propose to
associate a "content model" identifier with each page, and have handlers for
each model that provide serialization, rendering, an editor, etc.
The background is that the Wikidata project needs a way to store structured data
(JSON) on wiki pages instead of wikitext. Having a pluggable system would solve
that problem along with several others, like doing away with the special cases
for JS/CSS, the ability to maintain categories etc separate from body text,
manage Gadgets sanely on a wiki page, or several other things (see the link below).
I have described my plans in more detail on meta:
http://meta.wikimedia.org/wiki/Wikidata/Notes/ContentHandler
A very rough prototype is in a dev branch here:
http://svn.wikimedia.org/svnroot/mediawiki/branches/Wikidata/phase3/
Please let me know what you think (here on the list, preferably, not on the talk
page there, at least for now).
Note that we *definitely* need this ability for Wikidata. We could do it
differently, but I think this would be the cleanest solution, and would have a
lot of mid- and long term benefits, even if it's a short term pain. I'm
presenting my plan here to find out if I'm on the right track, and whether it is
feasible to put this on the road map for 1.20. It would be my (and the Wikidata
team's) priority to implement this and see it through before Wikimania. I'm
convinced we have the manpower to get it done.
Cheers,
Daniel
After adding $wgShowExceptionDetails = true; to LocalSettings.php
===========================
Internal error
Non-string key given
Backtrace:
#0 $wikipath/includes/GlobalFunctions.php(781): MessageCache->get(NULL,
true, Object(Language))
#1 $wikipath/includes/GlobalFunctions.php(902): wfMsgGetKey(NULL, true,
Object(Language), false)
#2 $wikipath/languages/Language.php(513): wfMsgExt(NULL, Array)
#3 $wikipath/languages/Language.php(525): Language->getMessageFromDB(NULL)
#4 $wikipath/languages/Language.php(799): Language->getMonthName(false)
#5 $wikipath/languages/Language.php(1560): Language->sprintfDate('H:i, j F
Y', false)
#6 $wikipath/includes/User.php(2970):
Language->timeanddate('9c175ace21c28db...', false)
#7 $wikipath/includes/specials/SpecialUserlogin.php(202):
User->sendConfirmationMail()
#8 $wikipath/includes/specials/SpecialUserlogin.php(132):
LoginForm->addNewAccount()
#9 $wikipath/includes/specials/SpecialUserlogin.php(34):
LoginForm->execute()
#10 [internal function]: wfSpecialUserlogin(NULL, Object(SpecialPage))
#11 $wikipath/includes/SpecialPage.php(851):
call_user_func('wfSpecialUserlo...', NULL, Object(SpecialPage))
#12 $wikipath/includes/SpecialPage.php(578): SpecialPage->execute(NULL)
#13 $wikipath/includes/Wiki.php(262):
SpecialPage::executePath(Object(Title))
#14 $wikipath/includes/Wiki.php(63):
MediaWiki->handleSpecialCases(Object(Title), Object(OutputPage),
Object(WebRequest))
#15 $wikipath/index.php(114):
MediaWiki->performRequestForTitle(Object(Title), NULL, Object(OutputPage),
Object(User), Object(WebRequest))
#16 {main}
=============================
The actual registration goes through because I can't re-register a nick
after this error. From the stacktrace I'm guessing the problem is sending
the email.
No idea how to debug, any pointers would be much appreciated.
Thanks in advance,
Joanna
Moin,
I made a small infobox to control the currentness of data. I wonder if
it is possible to declare a categorie out of this infobox?
Instead of filling out the infobox in a firtst step and including the
categorie in an other: just add a line to my infobox where my users can
type in the desired categorie.
Thanks
--
|Michael Renner E-mail: michael.renner(a)gmx.de |
|81541 Munich skype: michael.renner.gmx.de |
|Germany Don't drink as root! ESC:wq
Why does the button in MediaWiki say "Save Page"?
I might be editing a section, so it could say "Save Section" or maybe
"Save"....
Gordo
--
Gordon Joly
gordon.joly(a)pobox.com
http://www.joly.org.uk/
Don't Leave Space To The Professionals!
Hello,
Wgen trying to upgrade MediaWiki installation 1.17.0 to 1.18.2, the following happens when running ,aintenance/update.php:
Fatal error: Call to a member function getDbType() on a non-object in maintenance/doMaintenance.php on line 91
(all upgrade steps are made as recommended in the supplied document).
The DB is garbled after that, I had to reverse both files and reload DB dump to have site back in working state.
Is the above a known problem? PHP version is 5.2.17.
Thanks.
Sincerely,
Konstantin