I installed SMW extension in my local wiki yesterday and now when i visit a
page in my local wiki i get this message "A database query syntax error has
occurred. This may indicate a bug in the software. The last attempted
database query was:
(SQL query hidden)
from within function "ShortUrlUtils::encodeTitle". Database returned
error "1146:
Table 'my_wiki.w1_shorturls' doesn't exist (127.0.0.1)""
Along with the page being displayed untidily.
So i tried to fix the problem ,as suggested by people i tried to run "php
update.php"
Then i got the following error message
"A copy of your installation's LocalSettings.php
must exist and be readable in the source directory.
Use --conf to specify it."
I have my LocalSettings.php in the same place where my default index.php is
located,earlier i had made some logo changes to my wiki and they were
succesfully reflected in my wiki,so the localhost has access to the
LocalSettings.php
I am working on Ubuntu and have mediawiki 1.20 installed
Please Help!!Its Urgent
Thanks In Advance
Last week we held the LiquidThreads Bug Day on Tuesday March 19th [1] as a
part of the weekly QA activity [2].
*How it Went*
We triaged bug reports in the LiquidThreads component, which included
testing, prioritizing, and closing reports. We had 6 attendees, including
qgil, Krenair, Nischayn22, and geeklizzard.
*What we Achieved*
We triaged 31 bug reports on the bug day [3]. Contributors triaged
reports throughout the week as well, but not all of their contributions
were captured on the etherpad, so that's harder to measure.
*April Bug Day Topics *
I have created a thread [5] to propose and discuss April's bug day topics,
so if you have any topic suggestions, please reply there. Matma Rex has
already suggested triaging reports in the Interface component, and we're
looking for a topic for the second bug day of the month.
Thank you for your participation and support!
-Valerie
[1] https://www.mediawiki.org/wiki/Bug_management/Triage/20130318
[2] https://www.mediawiki.org/wiki/QA/Weekly_goals
[3] https://www.mediawiki.org/wiki/Bug_management/Triage/20130318#Results
[4] http://etherpad.wmflabs.org/pad/p/BugTriage
[5]
https://www.mediawiki.org/wiki/Project_talk:WikiProject_Bug_Squad#Bug_Day_T…
context
-------
i’m working on a mediawiki extension, http://www.mediawiki.org/wiki/Extension:GWToolset, which has as one of its goals, the ability to upload media files to a wiki. the extension, among other tasks, will process an xml file that has a list of urls to media files and upload those media files to the wiki. we want to notify the user who uploaded the xml file of completed media file uploads.
leaveUserMessage
----------------
i was looking for a method that would leave a message on a user’s talk page and found a reference in mediawiki 1.21 to User::leaveUserMessage() in the /includes/job/jobs/UploadFromUrlJob on line 122, but could not find the method in the includes/User.php file and found that it was removed in mediawiki 1.18.0.
question
--------
1. what is the recommended method for leaving a message on a user’s talk page?
2. is there an “easy” way to update a single message, e.g., we want to leave a summary message something like : “1,000 items have been setup to be uploaded to the wiki in the background via the wiki’s job queue. currently 21 of 1,000 items have been uploaded successfully. the following items could not be uploaded : * item 5, * item 7”.
thanks in advance!
dan
context
-------
i’m working on a mediawiki extension, http://www.mediawiki.org/wiki/Extension:GWToolset, which has as one of its goals, the ability to upload media files to a wiki. the extension, among other tasks, will process an xml file that has a list of urls to media files and upload those media files to the wiki. our ideal goal is to have this extension run on http://commons.wikimedia.org/.
job queue goals
---------------
1. setup the processing of the xml file as a job queue job
2. each media file upload to be setup as a job queue job
current implementation
----------------------
i have been able to achieve goal 2 and will sort out goal 1 shortly.
issues/questions
----------------
1. each of these jobs can take several seconds to complete. i have noticed in my local wiki that each of these jobs is picked up with each wiki visit and slows down the response of the wiki by however many seconds the job takes to run, a sleep in the job shows that if the job takes 15 seconds to run the wiki will be slowed down by that amount of time; i don't want this to happen on my local wiki or on commons.
a. are jobs on commons run as part of each wiki visit?
b. is there a cron job that takes care of the job queue on commons instead of using each wiki visit?
c. if not, is there a way to indicate that the job should only be run as a cron job and not with a wiki visit?
2. if there's no solution to running the job with each wiki visit and slowing down the site, what other suggestions are there on processing the xml file and individual media file uploads?
thanks in advance!
dan
I filed that yesterday as bug
46072<https://bugzilla.wikimedia.org/show_bug.cgi?id=46072>.
;)
I'll try to find time to review it before the weekend.
On Thu, Mar 14, 2013 at 3:55 PM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
> As some folks may recall, an action=createaccount was added to the API a
> few weeks ago. Unfortunately the first pass didn't include CAPTCHA support,
> so we haven't been able to use it for the live sites yet (which use
> ConfirmEdit's "FancyCaptcha" mode). We expect to start using this in the
> next couple weeks for the mobile Commons apps, so it's time to make it
> captcha-friendly...
>
> I've made a first stab at adding support, based on the existing captcha
> interfaces for login and editing:
>
> MediaWiki core: https://gerrit.wikimedia.org/r/53793
> ConfirmEdit ext: https://gerrit.wikimedia.org/r/53794
>
> So far I've tested it with the default 'math captcha' mode, with this test
> rig: https://github.com/brion/mw-createaccount-test
>
>
> If a captcha needs to be run, action=createaccount will spit back a result
> including a 'captcha' field including several subfields, such as in this
> example:
> https://www.mediawiki.org/wiki/API_talk:Account_creation#Captcha_additions
>
> Since account creation requires a first request to get a token anyway,
> this shouldn't significantly add to the complexity of using the API.
>
>
> Text captchas will have a 'question' subfield to be presented; image
> captchas will have a 'url' field which should be loaded as the image.
> 'type' and 'mime' will vary, and probably shouldn't be used too closely.
>
> Pass back the captcha id field in 'captchaid' and the response word in
> 'captchaword' parameters along with the final request, and it should pass
> the captcha. If the captcha doesn't pass, you get back new captcha info and
> can continue.
>
>
> Questions:
> * Does this seem to make sense? :)
> * Will other API users kill me for this or will it be easy to use?
> * Any surprises that may turn up?
> * Any bugs/style problems in my code so far?
>
> -- brion
>
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
>
>
--
Brad Jorsch
Software Engineer
Wikimedia Foundation
It's time to start defining what we want our Google Summer of Code to be
all about. Let's look at the ideas we are proposing to potential students:
https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects
Many of the ideas listed there are too generic ("Write an extension"),
improvements of existing features ("Improve Extension:CSS") or
work-in-progress tasks ("Fix Parsoid bugs"). Many others are not
directly related with development, and therefore not suitable either for
GSOC.
After this filtering, we seem to be left with:
* Article evolution playback tool idea
* An easy way to share wiki content on social media services
* Write an extension to support XML Sitemaps without using command line
* Extension:OEmbedProvider
* Add support for x3d 3D files to MediaWiki
* Allow smoother and easier Wikimedia Commons pictures discovery
* Build an interwiki notifications framework and implement it for
InstantCommons
* Automatic category redirects
(If you think your project should also be considered here please speak up!)
Most of these projects seem to be extension (and PHP?) centric. Can we
have more diversity? Maybe gadgets and templates are too simple for a
GSOC project? What about the mobile front? Do we have skin development
projects that could make it here? Anything in the DevOps area? Anything
the MediaWiki core maintainers would like to see happening?
It would be also nice to have more candidates benefiting specific
Wikimedia projects. Beyond Wikipedia, we have several proposals related
to Commons. Wikidata seems to be joining soon. What else? Could this be
a chance to help Wiktionary, Wikibooks or any other project with
specific needs craving for tech attention?
Also to the many students that have already showed their interest: feel
free pushing your project ideas now!
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
I know Aaron has spent a lot of time on the job queue. But I have
several observations and would like some feedback. The current workers
apparently select jobs from the queue at random. A FIFO method would
make far more sense. We have some jobs that can sit there in the queue
for extended periods of time, while others added after that point may
get completed in mere few minutes.
Second exposing job_timestamp via the API should also assist in
identifying issues. whether or not some job is being ignored or the
particular wiki is just extremely lagged.
I am monitoring a template modification to file links that occurred
about hours ago, with a job queue between 350,000 and 500,000 items
this delay seems excessive.