#529 Feature request: put the value of the MW magic word {{PAGENAME}} in an environment variable

[David Leaman]

It would be great to be able to access the value of {{PAGENAME}} from within a script being run through make. The cleanest way I can think of to implement this would be to have an environment variable named something like $MW_PAGENAME.

As a note for future development, it could be nice to be able to easily include arbitrary magic words in the environment. Perhaps something along the lines of:

$wwMagicWordsInEnvironment = array( "PAGENAME", "SITENAME" );

[Lee Worden]

SITENAME is already exported into the make jobs as $(WG_SITENAME), it turns out.

Implementation details: these environment variables are provided by ProjectDescription::env_for_make_jobs(), which constructs an array of key-value pairs for every make jobs, by WorkingWikiProjectDescription::generate_source_file_content(), which adds some source-file-related environment variables to that list while it's constructing the project's GNUmakefile, and by ProjectEngine, which adds some more when it calls make.

The full list as of now is:

WW_PUBLISH_URL = <a URL to which a filename can be appended, to link to a file in the current project, e.g. "http://lalashan.mcmaster.ca/theobio/projects/index.php/Special:GetProjectFile?project=X&filename=">
PUBLISH_URL = <the same, for backward compatibility>
WG_SITENAME = <the value of the $wgSitename php variable, e.g. "lalashan.mcmaster.ca">
WG_SCRIPT_PATH = <the value of the $wgScriptPath php variable, e.g. "/theobio/projects">

added by WorkingWikiProjectDescription:

WW_THIS_PROJECT_SOURCE_FILES = <list of all source files>
PREREQUISITE_PROJECTS = <list of all prerequisite projects' variable names, as given in the project description>

and added by ProjectEngine:

time-limit = <number of seconds to allow make job to run. used by the pe-make executable.>
<varname> = <directory path>, for each "varname" provided as an env. variable name for a prerequisite project in the project description, e.g. PROJECT_DIR_REFS = "/usr/local/workingwiki/working-directories/persistent/pe-ww/lalashan.mcmaster.ca/theobio/projects/Refs"
WW_THIS_DIR = <path of the current project's directory>
report-hostname = <1 if pe-make should output the hostname where the process is running into the .make.log file>
PATH = <executable path, e.g. "/bin:/usr/bin">
RESOURCES = <pathname of the resources directory, where the WorkingWiki makefiles and scripts are, e.g. "/usr/local/src/WorkingWiki/ProjectEngine/resources">
FOREGROUND_ONLY = <1 if make is running as a foreground process, i.e. not a background job and not exported to someone's desktop computer>

Sources: ProjectDescription.php, WorkingWikiProjectDescription.php, ProjectEngine/PESession.php

[Lee Worden]

PAGENAME would go in ProjectDescription. To make that happen, I need to give ProjectDescription's env_for_make_jobs function access to the current context, because that's where the name of the current page being parsed is. Assuming there is one. What will happen when project files are made in API calls? I'll have to make a point of telling the API what page I want the file for.

So who calls env_for_make_jobs?

• WorkingWikiProjectDescription::generate_source_file_content(), when it puts them into GNUmakefile
• ProjectEngine::fill_pe_request()

So neither of those has access to the parsing context either. I'm concerned I might have to pass it through a lot of functions.

• generate_source_file_content() is called by
  • WorkingWikiProjectDescription::find_source_file_content()
    • WWAction_remove_source_file (because that function is also the way to find out where the source file is stored)
    • WWApiGetProjectFile
    • WWApiRemoveFile
    • SpecialGetProjectFile
    • SpecialManageProject
    • WorkingWikiProjectDescription::all_source_file_contents()
    • WorkingWikiProjectDescription::pages_involving_project_files()
    • WorkingWikiProjectDescription::source_image_pages()
    • WWInterface::render_after_parsing(), in "click to add"
    • WWStorage::findAndOutputFile()
    • wwfDumpProjectToGit_now() (which I think is not used)
  • WWStorage::findAndOutputFile()
    • WWStorage::getAllChangesInPageRev()
      • nowhere!
• fill_pe_request() is called by
  • ProjectEngineConnection::call_project_engine()

Some of those things only care about the project file's location, and they don't need to pass good info to this thing. The number of those that do need to might be manageable.

My options are, I think:

• pass a context object all over the place, so this one function will know what's being parsed. It'll probably be useful for other things too.
• Have this one function call RequestContext::getMain() to get the request context, which is bad practice since using globals should be a last resort, but should work.
• Set a $ww global recording what page we're on, and then use it in there.

If I use a RequestContext object in whatever way, I'll have to allow for two cases - the case where the Title is the page being parsed, and the case where we're called from api.php and the name of the page is in a GET parameter.

I don't like all this - I need to sleep on it or something. I don't have any more time now anyway.

[Lee Worden]

Went with option 2 of the list in the previous comment: just use the global RequestContext object to figure out where we are, without passing it through a bunch of function calls. Seems to work when I tested it on a regular page, and when remaking the target in Special:GetProjectFile.

[Lee Worden]

Reopening because it doesn't do the right thing when called via api.php - for instance when using an AJAX link to create a background job. In this context it records the page name as "API". Soon, when lots of project files are being made in AJAX calls, I'm going to need to get the page name right.

[Lee Worden]

When using api to make a project file in a page, it's clear that PAGENAME should be that page. But what should it even be in a background job? Maybe just set it to "background job" or something.

[Lee Worden]

BTW, I don't think I can simply support arbitrary magic words because these each have to be implemented independently from the parser's magic words, at least the way i'm doing it currently. This is because you can only ask the parser for magic words while it's in the process of parsing something, and we can make project files at other times.

I could consider making a generalized process for passing on magic words that would only work during parsing... I could get that to work for project-file tags on pages. They would just be blank or something when a target is remade while viewing it on GetProjectFile or in a background job... I could provide an extra variable called $(WW_MAGIC_WORDS_AVAILABLE) or something.

[Anonymous]

Hmm. I didn't say anything before, but if it's going to be hard, I'll mention that I don't think it's good design. A file is logically associated with a project, not a page.

[David Leaman]

It's true that a file belongs to a project rather than to a page, that's a good point. I guess I'm trying to do something here that isn't what WW is primarily for: generating page content, rather than executing code decoupled from the page. Lee, is generation of page content something that WW ought to be able to do, or something WW happens to be able to do?

[Lee Worden]

WW distinguishes projects from pages for flexibility. You can choose whether to group a project's files on a page or not. So we definitely can't presume that a project is associated with a single page.

At the same time, partly at Jonathan's urging, we've developed a default mode where a page is closely associated with a near-synonymous project. So I think generation of page content might be spilling from the "happens to" to the "ought to" category.

In my mind, it's more like something that it would be useful to do, so I'm for it if it's not too much of a problem.

But since there are cases where project operations aren't clearly on any page, there will be cases where it doesn't make sense to define $(MW_PAGENAME). For example, as in my earlier comment, when making something in a background job, particularly if it happens in a multi-page project and you're asking it to make something that isn't referenced on any of the pages.

I've taken this request to mean "the page being parsed, if the make job happens while parsing a page." If you want it to mean "the page, if the project is equivalent to a single page," I think that's actually harder and I don't want to do it. But I think the former thing probably covers your needs?

[Lee Worden]

This code needs to be rewritten a little because it's using MediaWiki's RequestContext class at an inappropriately low level that's getting in the way of reusing WW code without MW. Need to have the WWInterface object know what the current page name is. Simple enough, but I need to trace through this code and get it right, so I'm making a note here for later.

[Lee Worden]

Rewrite is done, and passing my tests. Works when making files during page parse, and when making files by loading them dynamically after the parse is done. Also works when making a project-file tag within a .wikitext file that's being loaded dynamically, both embedded in a page and viewed using GPF. (In the last case the value given to $(MW_PAGENAME) is "Special:GetProjectFile".)