Hey all, I got a question according to performance of extension I am
working on, it's called Online Status Bar (source is in trunk/extensions/),
this extension is supposed to display status of users, who have it enabled
in preferences, somewhere on userspace (talk, userpace, etc.)
The current design of feature is that:
there is a table which has two columns, username, timestamp it is using as
engine memory because I believe it would work faster. (however I am not a
dba, so I don't know if it has significant performace improvement)
Users who do not have this enabled in preferences do never update this
table so I think there shouldn't be problem, however:
Users who have it enabled - everytime when they open any page on wikipedia,
it look up if they are present in the table (select using their username),
if it returns nothing, it insert them to table (1 write), if they are
present, it compare timestamp with current time and variable which contains
write-delay, it's 5 minutes as default and thanks to that, the table is
updated only in worst case every 5 minutes, or later (so if user refresh a
page like twice a minute it should only do 2 selects, no write), however
every 5 minutes it should write to that status table (update timestamp).
If someone open a userpage of that user, it should do max 2 selects in
order to detect the online status. (in case that user who look up the
status has also this feature enabled, otherwise 1 select)
The table is also supposed to be periodicaly cleaned (expired records), so
it's supposed to be very small.
So, does anyone have any suggestion to make it even faster? Ian Baker told
me that there could be some use of cache, however I am not really sure how
to implement it, what do you think about this conception, is there any way
to make it simpler and keep its functionality as it is?
I don't know if this is a correct place to ask, I don't know if there is
some mediawiki forum where I could ask which would be more suitable.
sumanah from #mediawiki suggested that I post here. I set up SVG support on
But, I noticed a few problems:
* SVG images distorted when thumbnails are generated using normal wiki image
rendered PNG images, 404 errors were returned. This happens for ALL kinds of
images when scaling is requested via URL.
In troubleshooting this I got as far as finding some info about thumb.php
and htaccess rewrite rules that are supposed to redirect the 404 URLs to
thumb.php so the images can be generated. It's all greek to me, and I'm
surprised it isn't working by default on my wiki.
I have no idea why the SVG images are being rendered all weird.
ImageMagick's /usr/bin/convert seems to be configured correctly in
localsettings.php, and I don't see any problems.
You can have a look at the bizarreness here (login Demo/test):
Note that the 200px URL resize link works because that image was generated
with a wiki link, and was cached. It was generated all skewed too...
View this message in context: http://old.nabble.com/Help%3A-URL-resizing-404%2C-SVG%27s-render-distorted-…
Sent from the WikiMedia General mailing list archive at Nabble.com.
I am using mediawiki 1.17 with vector skin.
Want to remove the sidebar from all pages permanently so that all contents will be shown in 100% width
This e-mail message and its attachments are for the sole use of the intended recipients. It may contain proprietary, confidential, privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: This e-mail message including attachment(s), if any, is believed to be free of any virus. However, it is the responsibility of the recipient to ensure for absence of viruses. Aircel shall not be held responsible nor does it accept any liability for any damage arising in any way from its use.
Now that Sam has announced the 1.18 Release Candidate, we'd like to make
sure that we've created a tarball that will work.
Please give 1.18RC1 a try and add your experience to
I just upgraded one of the wikis I maintain from 1.15 and recorded my
experience. Of course, as Sam writes in his announcement, you should
probably not do this on a production wiki "unless you are both very
brave and very confident in your MediaWiki administration skills." So,
maybe you'll want to try it in a test installation.
That said, let us know of your successes!
Of course, we'd like to know about failures, too, and that page is an
appropriate place to report them (in addition to bugzilla), but we
really need to know if this release is as good as we think it is.