User talk:Alexia E. Smith

Contents

PDFEmbed for android mobile

I have a mediawiki which many pdf which have been imported in it

your extension is OK for PC

but when I look the wiki pages with my mobile i have an error display as following

"The PDF file did not load properly or your web browser doesnot support viewing pdf files; Download <a href=......>exemple.pdf</a>directly to your device"

so at each time the pdf is loading on my mobile and it is necessary to exit for viewing it with a pdf reader

perhaps this extension may offer a new feature to work as the pdf embed existing for wordpress see here

(on this site the pdf can be view online with all browser firefox, chrome, opera with my pc but also with my android tablet

I hope this will be possible in the futute because somebody looks the wiki with their mobile

Short URL Pages

Alexia, MediaWiki handles routing of paths to pages internally using REQUEST_URI. Including a ?title=$1 inside of a rewrite overrides MediaWiki's internal correct handling of urls. And in the case of webservers with broken query escaping code like Apache can result in titles such as those including pluses and ampersands breaking. But either way it's incorrect when path routing in core is getting more complex and moving towards internal support for 404 handling, routing different types of url patterns, etc...

All the old short url guides were written without a complete knowledge of rewrites and how MediaWiki handles urls. With the same mistakes being repeated over and over. The large collection of guides is also very unfriendly towards users trying to get short urls working. New manual pages with the proper ways to setup short URLs are being written to replace all the old guides, with notes on all the edge cases included. And that knowledge is being put into a tool to generate full short URL configs based on various bits of information. The plan is to build up enough canonical information about short URL configuration for a future version of MediaWiki to have short URL configuration handling built into the installer so everyone can easily have it.

Btw, the Nginx manuals explicitly state not to use if() to test for file existence: http://wiki.nginx.org/Pitfalls#Check_IF_File_Exists Daniel Friesen (Dantman) (talk) 04:14, 4 April 2013 (UTC)

I have a complete knowledge of how Mediawiki handles URLs and did when that NGINX configuration was created. It does not break URL handling and issues with special characters are non-existent. For NGINX I could change the redirect to "rewrite ^/([^?]*)? /index.php/$1". That should work the same, but I have not personally tested it. This short URL setup has also been tested on Apache on Linux for the same issues.

Using NGINX's if directive is fine. "Using if to ensure a file exists is horrible. It's mean." It just says it is horrible, but with no quantifiable reason. "Just Because" is not a real reason. The if directive simply gives more flexibility for file handling. You could have linked to [1] instead, but that just also says using rewrites inside an if directive inside a location is fine for now. The current configuration shown does work and more importantly does work with version of NGINX before 0.7.27.(Those people really should upgrade though due to security flaws.) The internal NGINX configuration in use at Gamepedia is newer, does use try_files in cases where it makes sense, but does breaks backwards compatibility. The base NGINX configuration provided in the manual page should get anyone started to setting their wiki up on NGINX and still give them flexibility for tailoring it to their environment.

Alexia E. Smith (talk) 05:20, 4 April 2013 (UTC)

Not rewrite /index.php/$1. The /$1 is as unneeded as ?title=$1. You just want to send the request to index.php. You actually don't need nginx's rewrite engine at all. Unless you're trying to support the 404 thumb handler. Although in the future you won't need it for that either.

You can actually get short URLs working in /wiki with something as simple as this:

location /wiki {
	include /etc/nginx/fastcgi_params;
	fastcgi_param SCRIPT_FILENAME	$document_root/index.php;
	fastcgi_pass  127.0.0.1:9000;
}

And root urls can also be done by simply making that a @wiki and using try_files.

I've never seen a person with a version of nginx before 0.7.27. In fact other php projects like Drupal have already dropped support for nginx before that version and started using try_files. Daniel Friesen (Dantman) (talk) 06:06, 4 April 2013 (UTC)

PDFEmebed

I'm having a terrible time trying to get it to work. If I explicitly state a file name, it works great. But if I try to pass in the file name with a template, I get "The URL or file path given to embed a PDF is blank."

Is it something with the extension or some obscure feature of templates?

The template is along the lines of this:

<pdf width="500" height="800">{{{file}}}</pdf>

I've checked the value of the parameter "file" in various ways and it is passed. But not within <pdf>. Any help is appreciated

Fuddle (talk) 20:47, 28 December 2013 (UTC)

This is fixed now: https://github.com/Alexia/PDFEmbed/commit/a37ad4a033817abe83ed55d1da9ef8275bf921cc

Alexia E. Smith (talk) 17:33, 20 January 2014 (UTC)

I have never tested this with template functionality so it looks like it is bug with template interaction. I created a new issue ticket on the Github project to track the status of this. We will not get to until next week since our office is closed until after the new year starts.

https://github.com/Alexia/PDFEmbed/issues/1

Alexia E. Smith (talk) 21:33, 28 December 2013 (UTC)

I added the 3 lines of code, but I'm getting the same error. Is there something else I need to do? Fuddle (talk) 02:05, 23 January 2014 (UTC)

Same problem, when you use {{#var:...}} I added

if (strstr($file, '{{') !== false) { $file = $parser->recursiveTagParse($file, $frame); } Now it's fine. see Extension Talk --M art in (talk) 15:22, 25 January 2017 (UTC)

Code restructuring of DPL

Hi Alexia,

I was really happy to see that you are making efforts to improve the maintainability of DPL ("third party extension"). Some years ago I inherited the DPL source code and then gradually added more and more functions - but, sad to say, I never found the energy to improve its structure. A lot of my energy also went into the manual and supporting users.

Looking back, I wish I had thrown away the initial version and started from scratch. But I was always interested to use DPL ad hoc as it was in various projects and time was so scarce.

I would be glad if you came up with an improved version so that the code can have some more years of life expectancy. I still feel it is a useful extension and can do a lot of things which help to make wiki contents transparent.

Good luck, Gero Algorithmix (talk) 14:13, 14 October 2014 (UTC)

I have version 3.0 Alpha 4 up on Github to check out. https://github.com/Alexia/DynamicPageList/tree/3.0A4 If you have your own development wiki to test it on and preview it then give it a shot. Alexia E. Smith (talk) 15:46, 24 October 2014 (UTC)

DPL is nearly the number one extension used by our wiki team at Gamepedia. Unfortunately it is also the number one extension that causes slow page loads and errors. Debugging that 3,000+ line function is not fun! We rather see this extension flourish then see it die off or be replaced. Part of the goal with this rewrite it to add performance profiling so that we can identify costly functions and queries.

My progress is being tracked on Github over here: Alexia/DynamicPageList · GitHub. The extension currently does not function with all the code moving happening, but it should give an idea of what I am doing to it.(Everything is subject to change!) Once I finish I will get in contact with the DPL team for submitting it back to Gerrit.

Alexia E. Smith (talk) 15:24, 15 October 2014 (UTC)

Hi Alexia, are you still involved in DPL maintenance? The online manual at semeb.com/dpldemo has been down for some time and I took some effort to update everything to the latest MW release. I would like to cretae a ZIP file and hand it over to someone who keeps it going, Gero. (ANSWER only to gero.scholz(at)gmx.de please!) 77.176.144.215 13:22, 30 May 2017 (UTC)