#544 no dynamic files on Special:GetProjectFile

[Anonymous]

Seems like to be consistent, we want to load project file contents dynamically on GetProjectFile pages when we're doing it on regular pages. Currently it isn't doing it.

[Lee Worden]

Presumably because I put the dynamic case in WWInterface::display_project_file(), and GetProjectFile bypasses that function and calls WWInterface::display_file_contents().

So I need to sort out whether to have GPF call the higher level function, or move the check for dynamic display down into the lower level function, or do the check in the GPF code as well as in display_project_file().

[Lee Worden]

Sigh, Special:GetProjectFile is too complicated, so many cases, too intertwined, with making/not making, displaying in the page/dumping the file raw, retrieving the file/outputing error messages in the wiki page/outputing error messages in a 404 or 500 error page. I need to untangle it and deduplicate code with display_project_file().

[Lee Worden]

I was just looking at [#74], which is about having it detect binary files and display them as links rather than source, and I noticed this also would probably belong in display_file_contents. So maybe I'll go after both at once.

[Lee Worden]

So now, in detail, the different things that happen in these 3 places.

Special:GetProjectFile

• read in the URL parameters and fill in default values as needed
• do initial action (sync files, etc) if needed, and output its result.
• If filename is bad, complain and quit
• If project name is bad, complain and quit
• If appropriate, ask ProjectEngine to make the target file
• Figure out whether it's a file in the resources directory rather than in a project (this logic seems to be in a few disparate places in the code, but it probably makes sense, I'm not really looking at this part)
• Figure out default display mode of file based on its filename (using WWInterface::default_display_mode)
• Do a little dance with display=link and display=download to avoid circular links
• If file is going to be served raw and it's HTML, call display_file_contents to get its contents and then append .html to its filename (to make sure the browser recognizes the contents as html when it's output)
• If not serving file raw:
  • retrieve it from PE
  • if it's a directory, make the directory listing
  • if it's html, check the beginning of the file contents to decide whether it's a complete page or not: if it is, decide to serve the file raw.
• If serving the file raw:
  • guess whether it can go in browser tab or should be a download
  • if we have the file contents, serve up the file contents with appropriate headers
  • if we don't have the contents, ask PE to stream it, and pass the output verbatim to the browser
  • if anything went wrong, output a 404 or 500 error page (we need to do HTTP stuff correctly here, so that the browser will do the right thing as we're using GetProjectFile to display images).
• If we get this far, we're not displaying the file raw. Create the output page's title, etc.
• Report any WW errors that have occurred while retrieving the file or anything.
• Construct the bracketed links, including 'make', 'page', 'download', 'upload', etc.
• Produce "make succeeded but did not create file" or, if make wasn't done, "file not found" message if appropriate.
• call display_file_contents to produce the output html representation of the file.
• report any errors.

[Lee Worden]

WWInterface::display_file_contents( &$project, $filename, $text, $display_mode=false, $loglink=true, $line=false, $args=array(), $parser=null, $getprojfile=false ):

• infer the default display mode if not given
  • (with a special case to replace display=link by display=download if displaying in GetProjectFile)
• if it's display=link or download, construct the URL and return an HTML a tag.
• if it's an image to be displayed inline, return an HTML img tag
  • except if it's an SVG image, it's an object tag
• if it's xhtml, and we're not serving an xhtml-compatible page, do a filename switch (the HTML "fallback" - now effectively obsolete, since we don't use XHTML for latex any more) by replacing '.xhtml' => '.html'.
• Get the file contents from PE, or possibly (if it's a source file) from the wiki (does it do this? when?).
• If the file's too big, emit a warning and switch to display=link.
• If displaying as HTML, return the HTML.
  • Rewrite links within it, to URLs of project files in the same project.
  • If it's a complete page, output an HTML iframe to embed the file in the containing wiki page.
  • Attach the altlinks
    • outside the iframe
    • or just before the html file contents
    • or in some cases (LaTeXML) insert the links into the html so they float alongside the document title
    • or if it's a standalone such as a snippet of latex math, make the math itself be a link to the log file instead of having a [log] link in the margin.
• If it's wikitext, parse it and return the result.
• If it's display=source, construct a <source> tag and give it to the wikitext parser, which will get the SyntaxHighlight_GeSHi extension to produce a highlighted version of the source.
  • just use <pre> if the syntax highlighter isn't installed
  • make filenames into GPF links after highlighting, if it's a makefile
• If it's not any of these things, produce an error message saying we don't know how to display it. I've never seen this happen. It's probably impossible, because there's code upstream that assumes the display argument is a product filename if it's not one of the standard things.

[Lee Worden]

WWInterface::display_project_file(&$project,$text,$source,$args,&$parser):

• call file_to_display to infer what to display, e.g. if it's a .tex display a .html, etc.
• if $args doesn't say explicitly whether to make, insert the default answer (true unless it's a source file).
• If we're viewing an old revision of the page, and it's not a source file, refuse to display it.
• If we're using dynamic loading of project files, output a placeholder that'll be filled in with the project file contents by the client.
• Sometimes pages get parsed while we're storing the updated values of archived project files. If this is happening, leave project files out to avoid extraneous make operations.
• If a make operation is needed, do it.
• If display=none, return nothing.
• Otherwise call display_file_contents to construct the HTML for the file.

[Lee Worden]

And are these functions called from other places?

display_project_file: no

display_file_contents: is used by the API when dynamically loading a project file.

[Lee Worden]

So is there much overlap between display_project_file and the stuff GPF does?

• They both decide whether to make, but using different logic
• They both do the make operation
• They both construct altlinks, but differently
• I want them both to do the dynamic project-file placeholder

Also, both GPF and display_file_contents seem to be worrying about display=link on the GPF page. I could review that to see if it can be simpler.

In general, it seems like the division of labor is actually pretty good. So I'll leave these functions pretty much as they are. To solve the original problem - GPF doesn't produce the dynamic file placeholder - I can either add the placeholder code to GPF - maybe making a function for it, to avoid code duplication, or maybe not, since it's so short - or move it into display_file_contents. I think I'll make it into a function, since that seems like a good way to customize the placeholder message, and I'm guessing I might want that to be different on GPF.

[Lee Worden]

When GPF retrieves a file dynamically, the returned text will include the alt links. So I guess I'll have to change how the GPF-style alt links are produced.

I guess this has to happen anyway, because I think altlinks ultimately want to be pretty different for dynamic files. They will want to include things like reload and remake, which don't make sense with static files. Also, I picture switching to a different interface where you hover and the action links drop down, instead of being all strung out between square brackets.

So. Let's say that in the future they'll be returned by the API as a separate little data structure, not stuffed within the HTML code it produces. And that the placeholder may also include data telling it to put some extra links, like upload, remake, etc.

Let's see if we can do that with the extra links in the placeholder now, and if not let's go ahead and implement the other part.

[Lee Worden]

Closing this ticket, with the alt-links issue now tracking at [#547] and detection of binary files still open at [#74].