User talk:Alexia E. Smith

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 exemple.pdfdirectly 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  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:

I've checked the value of the parameter "file" in various ways and it is passed. But not within. 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  I added

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)

How to get the "https" into the iframe-src attribute? (PDFEmbed)
How to get the "https" into the iframe-src attribute? Like this:  Thank you!

Test pages
I've deleted your test page at /example.com per your edit/request on the page. In the future, it is likely better to perform such tests on the test wikipedia or some other test wiki rather than here. Thanks! -- Skiz zerz  04:38, 28 August 2019 (UTC)

Email
Hi, I've sent you an email regarding SpriteSheet, I'd appreciate if you could give it a look. Reception123 (talk) 18:36, 6 April 2020 (UTC)

File:EmbedVideoExample1.jpg and File:EmbedVideoExample2.jpg
Hello Alexia,

since I had to delete and  due to missing valid license, I guess your extension EmbedVideo needs new pictures.

Greetings, Tim (SVG)  06:47, 25 May 2020 (UTC)


 * I won't be making new ones. Alexia E. Smith (talk) 06:49, 25 May 2020 (UTC)

Sure, that's your decision. I just wanted to inform you about the deletion. Tim (SVG) 06:57, 25 May 2020 (UTC)
 * I've recreated the first image using a creative-commons-licensed video and uploaded it to Commons. I don't think I have good enough image editing skills to recreate the second image. * Pppery * it has begun 16:54, 25 May 2020 (UTC)

Merge request for table sorting
Hi there -- I submitted a merge request for DynamicPageList about a month ago. It fixes a sorting problem and it's 100% backward compatible. Any chance you could consider this request? Thank you very much for maintaining an absolutely fantastic MediaWiki extension. --Maiden taiwan (talk) 21:21, 27 June 2020 (UTC)

Actor Migration compatibility for MW 1.35
Is there any way you could please make DPL3 compatible with MediaWiki 1.35? At current folks that are being asked to upgrade by their host providers are unable to because DPL3, which they rely on heavily, is not compatible with 1.35 and its status on its extension page updated to make this clearer to users. At the moment we're going to try to swap to DPL2/third-party but as many of the same makers are listed on both, we fear they both suffer from the same issue, missing compatiblilty for Actor Migration which is needed in 1.35. If you could take a look at this, I would be eternally grateful. There are many wanting to update to 1.35 for the built-in php parsoid and VE support out of the box with no need for restbase on smaller wikis, which is a huge draw to smaller wikis due to ease of use/setup. We just upgraded a clone of our wiki to 1.35 and discovered continued database errors being caused by DPL3 and we're stuck not able to upgrade. So we'd be very thank for for added compatibility for the current MediaWiki release, thanks! TiltedCerebellum (talk) 01:46, 13 November 2020 (UTC)