Can you get access to a pages front matter (or other data) in a eleventy (11ty) plugin - plugins

I'm creating (would like to create) an eleventy (11ty) plugin that can automatically generate Open Graph images based on a pages data. So in the template:
---
generate_og_image: true
image_text: "text which will be baked into the image"
og_image_filename: some_file_name.jpg
---
#some markdown
...
I can process each file in my .eleventy.js file via plugin using:
module.exports = function (eleventyConfig) {
eleventyConfig.addLinter("og-image-generator", function(content, inputPath, outputPath) {
title = HOW_TO_ACCESS_TEMPLATE_FRONT_MATTER
createImage(title)
});
}
But only have access to the content, inputPath and outputPath of the template.
How can I access the front matter data associated with the Template? Or is there a better way to go about this?

Answering my own question. As #moritzlost mentioned it is not possible directly. I found this workaround.
eleventyComputed allows you to dynamically assign values to keys. It also allows you to call a custom shortcode.
You can pass whatever properties you like from the template into the shortcode. In this case ogImageName the image name, ogImageTemplate a template or background image and text which is the text to be written on that background.
You can even pass in other keys from your front matter and process them as you go.
---
layout: _main.njk
title: "Some title here"
eleventyComputed:
ogImageName: "{% ogCreateImage { ogImageName: title | slug, ogImageTemplate: 'page-blank.png', text: title } %}"
---
Then in .eleventy.js or a plugin:
eleventyConfig.addShortcode("ogCreateImage", function(props) {
const imageName = props.ogImageName
const imageTemplate = props.ogImageTemplate
const imageText = props.text
console.log('-----------------ogCreateImage-----------------');
console.log(`filename: ${imageName}`);
console.log(`using template: ${imageTemplate}`);
console.log(`with the text : ${imageText}`);
// call the image creation code — return filename with extension
const imageNameWithExtension = createOGImage(imageName, imageTemplate, imageText)
return imageNameWithExtension
});
Returning the final filename which you can use in your template.

I've also come across this problem. I don't think what you're trying to do is possible at the moment. There are not many ways for a plugin to hook into the build step directly:
Transforms
Linters
Events
I think events would be the best solution. However, events also don't receive enough information to process a template in a structured way. I've opened an issue regarding this on Github. For your use-case, you'd need to get structured page data in this hook as well. Or eleventy would need to provide a build hook for each page. I suggest opening a new feature-request issue or adding a comment with your use-case to my issue above so those hooks can be implemented.
Other solutions
Another solution that requires a bit more setup for the users of your plugin would be to add your functionality as a filter instead of an automatic script that's applied to every template. This means that the users of your plugin would need to add their own template which passes the relevant data to your filter. Of course this also gives more fine-control to the user, which may be beneficial.
I use a similar approach for my site processwire.dev:
A special template loops over all posts and generates an HTML file which is used as a template for the generated preview images. This template is processed by eleventy. (source)
After the build step: I start a local server in the directory with the generated HTML files, open them using puppeteer and programmatically take a screenshot which is saved alongside the HTML templates. The HTML templates are then deleted.
This is integrated into the build step with a custom script that is executed after the eleventy build.
I've published the script used to take screenshots with Puppeteer as an NPM package (generate-preview-images), though it's very much still in alpha. But you can check the source code on Github to see how it works, maybe it helps with your plugin.

Related

Word addin, set filename

If one starts a blank file on Word you can usually see in the top bar a name such as "Document1", "Document2" and so on.
Yet, if you attempt to open a file using the Word JS API like this:
Word.run((context) => {
context.application.createDocument(documentB64).open()
return context.sync()
})
The top bar comes out like this:
No filename is set.
To set a filename/handle(?), I tried using the code given here Office JS - Add customProperty to new document but that didn't help.
My addin is usually used in conjunction with another (VSTO) add-on and that add-on can't work properly with the documents opened by my addin and I believe the lack of a filename (/handle?) explains it to some extent.
Is there something I can do about this?
Thank you
Currently you can't do this because the newly created document is just a temporary file and not saved. can you try to call the following code to make sure the newly created file is saved?
const documentCreated = context.application.createDocument(externalDoc);
documentCreated.save();
documentCreated.open();

How to avoid opening a QuickInput when choosing files to compare in a vscode extension?

In my case I want to compare two files.
But I don't want the user to select the File in the QuickInput form, i want to choose this directly for him.
vscode.commands.executeCommand("workbench.files.action.compareFileWith", filePath)
This results in
Meaning that filePath is ignored and a QuickInput is displayed instead.
Is there a way to directly select a file programmatically instead of showing the QuickInput first?
While the compareFileWith command probably requires a QuickInput panel to use, you can use the other compare commands to do what you want:
// using the current file for the 'compareWith' file
const currentFileUri = vscode.window.activeTextEditor.document.uri;
// create a Uri from some filePath
const compareWithSelectedUri = vscode.Uri.file('C:\\Users\\Mark\\OneDrive\\Test Bed\\BAR.txt');
await vscode.commands.executeCommand('selectForCompare', currentFileUri)
await vscode.commands.executeCommand('compareFiles', compareWithSelectedUri);
This works in my testing.
Looking at compareFileWith in https://github.com/microsoft/vscode/blob/9b9361cfd1b0678f0bb0b32bf9925b6520bb9926/src/vs/workbench/contrib/files/browser/fileActions.ts I don't think there is any way to avoid the QuickInput opening.
Alternatively, what you are asking for would be "easy" if an open method were supported on TabGroups api like the close methods. You would create a tab of kind TabInputTextDiff with an original uri and a modifieed uri.
When the TabGroups api was being developed there was an open tab method but it was removed prior to release and hasn't seen any love since. See https://github.com/microsoft/vscode/commit/aa69f3d7623c464aba726d12ea0d83428f43e8b9#commitcomment-71831337.
I'll open an issue to see if it will help (and post the link here later).

How to work with FileSystemProvider file systems in Visual Studio Code

I've noticed the new FileSystemProvider API which looks great, but it seems that there is an expectation for plugins to be able to handle files within any custom file system created using this interface.
I've tried using node’s built in fs, which won't work, because the path within a Uri doesn't relate to the filesystem on the host machine, but to the arbitrary filesystem defined in another extension.
I've also tried the following (with the test memfs extension in use):
let uri = new vscode.Uri('memfs', '', fileName);
let fsp = new vscode.FileSystemProvider();
fsp.writeFile(uri)
.then(() => {
console.log('written file');
});
But it doesn't seem that FileSystemProvider exposes itself in the way I was expecting.
How, if at all, can a plugin make use of and perform file operations on URIs which are in the custom schemes that these arbitrary file systems can possess?
I ran into the same problem. It turns out FileSystemProvider is an interface that a provider should implement.
There is a great sample from Microsoft on GitHub.
The crux of it is this:
First, they create a new class called MemFS, which implements vscode.FileSystemProvider.
Then they register it like this:
const memFs = new MemFS();
context.subscriptions.push(
vscode.workspace.registerFileSystemProvider('memfs', memFs, {
isCaseSensitive: true
}));
The first parameter to registerFileSystemProvider is the scheme, which means that file system provider will be used whenever you use a URI starting with memfs://.
So you use fs as normal, and the scheme determines the FileSystemProvider that will actually be used. This is great, because it really makes it transparent to you whether the file being manipulated is on the disk, some server on the other side of the world, or dynamically generated by the provider.

Is there a detailed documentation on how to create own jsdoc templates?

Short version:
If I wanted to develop a completely new jsDoc template from scratch, what would I have to read to understand what jsDoc does, what interface my template must provide and what data I get to work with?
Long version:
I've been using jsDoc for a while now and have come across some tags that I would like to add and overview pages that I would like to have generated out of my documentation. Up to now I solved all my "user problems" with usejsdoc.org. I even managed to add a new jsdoc plugin that adds some tags. However, I can't find any developer documentation on how to create templates for jsdoc. I use ink-docstrap so I clicked my way through the template-folder (publish.js, /tmpl, etc.) and somehow got the idea of how everything works. But its very very time consuming.
What should I read to become a jsDoc template pro?
These instructions are the closest I could find:
To create or use your own template:
Create a folder with the same name as your template (for example, mycooltemplate).
Within the template folder, create a file named publish.js. This file must be a CommonJS module that exports a method named publish.
For example:
/** #module publish */
/**
* Generate documentation output.
*
* #param {TAFFY} data - A TaffyDB collection representing
* all the symbols documented in your code.
* #param {object} opts - An object with options information.
*/
exports.publish = function(data, opts) {
// do stuff here to generate your output files
};
To invoke JSDoc 3 with your own template, use the -t command line option, and specify the path to your template folder:
./jsdoc mycode.js -t /path/to/mycooltemplate
Failing that, you can read the source code!
I am running into a similar difficulty with lack of documentation. There is a GitHub issue that has been open for 7 years on this: Provide docs that explain how templates work.
The only example I've found so far of a custom template that doesn't look like just a modified version of the default is Ramda's documentation. It looks like they use a completely custom publish.js script that uses handlebars.js instead of underscore.js templates, constructs a non-hierarchical nav, pulls info from #sig and #category tags, and uses links to github for 'view source' instead of rendering its own html pages for source code.
Some of their code will be difficult to understand unless you are familiar with Ramda and functional programming (they use Ramda itself in their version of publish.js) but dumping out the values of data and docs during execution should help provide insight into what is going on.
It is helpful as well that their template is a single file so you don't have to jump between a lot of partial template files to follow how the doc is constructed.
I've just published my own new jsdoc theme. What I did is I simply copied the default template: https://github.com/jsdoc3/jsdoc/tree/master/templates/default, and worked on that.
I also managed to add grunt with the following features:
* transcompile + minify js files
* parse sass styles and minify them
* refresh the docs when you change something
You can see how it works here: https://github.com/SoftwareBrothers/better-docs
you can customize one of existing templates (default, haruki or silent):
go into node_modules/jsdoc/template and grab on of them into your app directory outside node_modules.
feel free to rename the dir ex: jsdoc-template.
open jsdoc-template update/customize the content as you want. ex: open publish.js find Home and replace My Js App.
update jsdoc.json by adding:
"opts": {
"template": "jsdoc-template"
}
another option to use one of those templates too: jsdoc3 template list examples
Followup to my previous comment about Ramda's JSDoc template. I've since created a customized version of it and published it on GitHub at https://github.com/eluv-io/elv-ramdoc
This is tailored for my company's projects, but it may be helpful as another learning tool. It adds a 'Show private' checkbox, updates Bootstrap to v5.13, replaces Handlebars with Pug, adds JSDoc comments to the publish.js script itself, and supports setting an environment variable to dump data to console during doc generation.

Display an older version of a CQ page

For audit purposes I got the requirment to create a tool where the authors can look at older versions of a CQ page. I managed to get the available versions with the JCR VersionManager using the following code (used in a SlingServlet with cq:Page as the resourceType):
Session session = request.getResourceResolver().adaptTo(Session.class);
VersionManager vm = session.getWorkspace().getVersionManager();
VersionHistory versionHistory = vm.getVersionHistory(request.getResource().getPath());
VersionIterator vIt = versionHistory.getAllVersions();
while (vIt.hasNext()) {
Version version = vIt.nextVersion();
String no = version.getName();
Calendar createdDate = version.getCreated();
// do something with it
}
The path of the version points to e.g. /jcr:system/jcr:versionStorage/d6/23/4f/d6234f36-3360-4024-bee2-411020ac63ae/1.0 where I can see a child node called jcr:frozenNode which seems to represent the jcr:content node of this specific version.
How can I tell CQ to render the page in this version? I would expect an url with some parameter or selector, but I didn't find any documentation. I tried to reverse engineer it with the Timewarp, but there the URL seems to be still the original and the magic is hidden somewhere.
I was also in contact with adobe support regarding this, and beside the timewarp there seems to be no built in feature to achieve this. Nevertheless I did some experimenting and found a feasible workaround. Though it might not be easy for a complex layout with many fixed components in the template, luckily on our case we mainly have a parsys.
So my solution is the following: I load the older version through two selectors in the url:
I called it "versionhistory" which is used to take another rendering script called versionhistory.jsp on the page component.
contains the actual version/node name (replacing "." with "_" to not add more selectors
In my versionhistory.jsp I just add the correct path for the parsys component (taking the example path from the question), and include the same layout elements as in the default script e.g. page.jsp:
<cq:include path="/jcr:system/jcr:versionStorage/d6/23/4f/d6234f36-3360-4024-bee2-411020ac63ae/1.0/jcr:frozenNode/par" resourceType="foundation/components/parsys" />