What is in the folder "src: '/zappa/" - what are these files - coffeescript

What is '/zappa/full.js'
I have some code with a /zappa/zappa.js file (ethercalc) and the tutorial has /zappa/full.js and there is even a /zappa/simple.js in the examples.
What are these files, what is the difference, any docs?
e.g. /zappa/full.js from https://zappajs.github.io/zappajs/docs/crashcourse
#get '/': ->
#render 'index'
{doctype,html,head,title,script,body} = #teacup
#view index: ->
doctype 5
html ->
head ->
title 'Client-side zappa'
script src: '/zappa/full.js'
script src: '/index.js'
body ''
Also I get a not found error with /zappa/full.js and have no idea if I can use /zappa/zappa.js instead.

zappa middleware serves
From https://zappajs.github.io/zappajs/docs/reference#root-scope
zappa
This zappa middleware serves /zappa/simple.js, /zappa/full.js,
/zappa/zappa.js, /zappa/jquery.js and /zappa/sammy.js. It is
automatically added by #client and #shared if not added before, which
means that in most cases you don’t need to #use 'zappa'. To minimize
page download delay on the client, prefer /zappa/full.js, which
combines Zappa, jQuery, Sammy.js, and Socket.IO client-side scripts
into a single download. If your client-side code doesn’t require
Sammy, use /zappa/simple.js which combines Zappa, jQuery, and
Socket.IO.

Related

Dynamic Links from a CMS - Error: "redirect" can not be returned from getStaticProps during prerendering

I have a Next JS app connected to a CMS and hosted on Vercel - all links are dynamic and the pages are created by the content authors.
I am trying to create dynamic redirects that will force URLs to adhere to formats that are better for SEO. For example:
Enforce lowercase URLs
Replace spaces with dashes
Remove trailing slashes
For example, /test/Author Name/ would redirect to /test/author-name
Since I need to trigger a 301 redirect for these wrong URLs, the only way to do this with Next JS from what I have found is to return a Redirect from getStaticProps, this is what I have so far:
export const getStaticProps: GetStaticProps = async (context) => {
let requestedUrl = '/';
if (context?.params?.path) {
requestedUrl = '/' + (context?.params?.path as string[]).join('/');
}
//check for URLs with uppercases, spaces, etc. and clean them up
let modifiedUrl = requestedUrl;
modifiedUrl = modifiedUrl.trim().toLowerCase().replace(/\s\s+/g, ' ').replace(/\s/g, '-');
if (modifiedUrl != requestedUrl) {
return {
redirect: {
destination: modifiedUrl,
permanent: true,
},
};
}
This works wonderfully well running locally and connected to the CMS - everything is working as it should and all "faulty" URLs are corrected with the correct response code.
Sadly, this does not work on build, I have spent so much time so far trying to find an alternative, but no matter what I do, the build on Vercel fails with the error:
"redirect" can not be returned from getStaticProps during prerendering
The next best potential solution is to use Middleware, but that requires v.12 at least. Due to limitations from the CMS connector, we are forced to use Node v.11 :(
The alternative that I have built is to use router.push on the client side, but this... just looks terrible. The page loads, returns a 200, and then loads again with the corrected URL. Not good for the user's experience.
Any advice or suggestions? I am baffled that something this simple is this complicated with Next JS!
I resolved the issue... it looks like redirects on statically generated pages are not possible unfortunately. I removed getStaticProps and getStaticPaths, and added getServerSideProps instead. The redirects are now working correctly, but the site is not as fast as we are losing out on SSG.

TYPO3 v10: How to access TSFE in Backend/Scheduler Task?

The current situation:
I am trying to access the TypoScript configuration of the frontend from within the backend (or rather a scheduler task). Previously with Typo3 v8 and v9, I initialized entire $GLOBALS["TSFE"] object, however this was already hack the last time around (using mostly deprecated calls) and now it has all been removed with the v10 release.
My goal:
Access the TypoScript configuration of the frontend of a certain page (root page of a site would be fine) from within a scheduler job.
Background of the whole project:
I have a periodic scheduler job that sends emails to various users (fe_users). The email contains links to certain pages (configured UIDs in typoscript) as well as file attachments and the likes (generated by other extensions, which are also fully configured via typoscript). Currently, I basically initialize the entire frontend from within the backend, but as I said before, its inefficient, super hacky and I doubt it was the intended way to solve this problem.
Getting TypoScript settings in the backend is ugly, but possible.
You need a page ID and a rootline which you can pass to \TYPO3\CMS\Core\TypoScript\TemplateService::runThroughTemplates().
Something along these lines:
$template = GeneralUtility::makeInstance(TemplateService::class);
$template->tt_track = false;
$rootline = GeneralUtility::makeInstance(
RootlineUtility::class, $pageId
)->get();
$template->runThroughTemplates($rootline, 0);
$template->generateConfig();
$typoScriptSetup = $template->setup;
You can get inspiration from \TYPO3\CMS\Extbase\Configuration\BackendConfigurationManager::getTypoScriptSetup and \TYPO3\CMS\Tstemplate\Controller\TypoScriptTemplateObjectBrowserModuleFunctionController
This won't get any better and is not intended to be done such way. I would use as configuration:
plain PHP, e.g. in $GLOBALS['TYPO3_CONF_VARS]`
YAML site config if depending on various sites
You can build links by using e.g. something like that
protected function generateUrl(int $pageId, int $recordId)
{
$additionalParams = 'tx_xxxx[action]=show&tx_ixxxx[controller]=Job&tx_xxxx[job]=' . $recordId;
return BackendUtility::getPreviewUrl($pageId, '', null, '', '', $additionalParams);
}

nginx: rewrite a LOT (2000+) of urls with parameters

I have to migrate a lot of URLs with params, which look like that:
/somepath/somearticle.html?p1=v1&p2=v2 --> /some-other-path-a
and also the same URL without params:
/somepath/somearticle.html --> /some-other-path-b
The tricky part is that the two destination URLs are totally different pages in the new system, whereas in the old system the params just indicated which tab to open by default.
I tried different rewrite rules, but came to the conclusion that parameters are not considered by nginx rewrites. I found a way using location directives, but having 2000+ location directives just feels wrong.
Does anybody know an elegant way how to get this done? It may be worth noting that beside those 2000+ redirects, I have another 200.000(!) redirects. They already work, because they're rather simple. So what I want to emphasize is that performance should be key!
You cannot match the query string (anything from the ? onwards) in location and rewrite expressions, as it is not part of the normalized URI. See this document for details.
The entire URI is available in the $request_uri parameter. Using $request_uri may be problematic if the parameters are not sent in a consistent order.
To process many URIs, use a map directive, for example:
map $request_uri $redirect {
default 0;
/somepath/somearticle.html?p1=v1&p2=v2 /some-other-path-a;
/somepath/somearticle.html /some-other-path-b;
}
server {
...
if ($redirect) {
return 301 $redirect;
}
...
}
You can also use regular expressions in the map, for example, if the URIs also contain optional unmatched parameters. See this document for more.

ZK8 Filedownload.save Cut Filenames

I use "Filedownload.save" to download files with Zk, but i have a problem.
Zk cut my filenames in some characters, for example, if the linema is "FISH#CHIPS.pdf", the file dowload as "FISH.pdf"
Anyone knows how to solve it?
UPDATE:
I have follow the instructions, and i finally see that the server response this JSON:
{"rs":[["download",["/myApp/zkau/view/z_aq5/dwnmed-3/son/FISH#CHIPS.pdf"]]],"rid":9}
And i am lost now, what do Zk with this JSON on the cliente side?
The official ZK-Bug is tracked as ZK-3809
A server side workaround is the following:
split download code such as ...
Filedownload.save("test content", "text/plain", "test#test.txt");
... into ...
AMedia media = new AMedia("test#test.txt", "txt", "text/plain", "test content");
Clients.response(new AuDownload((DeferredValue) () ->
Executions.getCurrent().getDesktop().getDownloadMediaURI(
media, "test#test.txt").replace("#", "%23")));
... allowing to encode special chars as needed.
UPDATE: ZK-3809 has been fixed and will be included in ZK version 8.5.1
The problem is that # is one of those "reserved characters" that, while valid in a URL, are treated in special ways. Look at this question for more details. My guess is that everything after the # is interpreted as a fragment on the page, and hence ignored in this case.
There are ways to fix this, for example by replacing # by %23. But doing this on the server side when calling Filedownload.save changes the filename to literally FISH%23CHIPS.pdf.
Instead, we can intercept the client side method that downloads the file when the response you showed arrives. This way, zk will still give the file its normal name, and only the download will sanitize the URL. Add this to a script tag or loaded js file:
zk.afterLoad('zk', function() {
var oldMethod = zAu.cmd0.download;
zAu.cmd0.download = function(filename) {
return oldMethod(filename.replace(new RegExp('#', 'g'), '%23'));
}
});
Then it will download the file with the complete name. You might want to take the extra time and sanitize the other reserved characters as well. Read this wiki article about "percent encoding" for the right codes.
I have also filed a support ticket with zk, I think this should be handled by the client side method out-of-the-box.

Mojo Routes: Handle asorted tags in url

I am building a Mojo app to replace a vanilla mod_perl application.
The app currently handles url structures like:
/
/type/bold/
/keyword/hello/
/audience/all/
/type/bold/keyword/hello/
/keyword/hello/audience/all/
/keyword/hello/type/bold/audience/all/
/audience/all/type/bold/keyword/hello/
key/value pairs in the URL, that can exist in any order.
I am looking for a way to handle that without simply making a route for every permutation of tag, as that gets repetitive even after 3 different types of tags
In that case you should probably just make a route that matches everything and parse the url yourself.