From what I understand the default method of uploading to MediaWiki is using the upload page.
However, on MediaWiki's own site and WikiPedia you are able to upload images via the page editor (Visual Editor or Enhanced Wiki Editor). Seems like I don't have the upload tab that MediaWiki has. Is this custom functionality or something I can enable?
Found the answer. This feature is called "cross-wiki upload" and is available in the 1.27 Alpha release. I was using 1.26 which is the latest stable release at this time.
https://www.mediawiki.org/wiki/Cross-wiki_upload
Related
I would like to add URL links into a web-based Google Drive folder. Searching online, it appears that this was once possible with files that ended in a .glink extension. I'm looking for documentation on the file format so that I can create them programmatically.
[EDIT] Why do I want to create .glink files? Because I want links (bookmarks, URLs) to be able to appear in my Google Drive web page and to be able to click on them an go to the page. Microsoft OneDrive supports this functionality.
GLINKS Files
The URL link file feature was available due to a workaround with Back Up and Sync before being deprecated with Drive for Desktop. The .glink seems to be patched and no longer available as it was also part of a third party tool no longer available. It seems it now only saves them as .URL and automatically gives it the icon for Google Docs, as it would take it as a simple file with text.
Checking the .url type file of Windows, when uploading to Drive it does not update as it should, even utilizing Drive for Desktop (as an alternative to sync data like back up and sync) the outcome is the one suggested above.
This is the main reason why there is no longer any documentation about the matter, due to this one not being an official feature and being also fully deleted, it can be confirm by the file type available when creating files with the Drive API:
https://developers.google.com/drive/api/guides/ref-export-formats
I would suggest to request a feature to allow this or to provide a new way to store URL links as before or report it to review if possible any references on how it used to work by submitting a feature request or checking the issue tracker about the matter:
https://issuetracker.google.com/issues/new?component=191650&template=824106
You can also add the details of the previous threads or discussions about the GLINKS.
What am I not seeing? The RTD features page says:
PDF Generation
When you build your project on RTD, we automatically build a PDF of
your project’s documentation. We also build them for every version
that you upload, so we can host the PDFs of your latest documentation,
as well as your latest stable releases as well.
But how do you find the PDF version? A websearch finds this 2012 blog post where the writer says:
Here, for example, is the url to Django-Tastypie’s PDF docs:
http://media.readthedocs.org/pdf/django-tastypie/latest/django-tastypie.pdf
You can replace django-tastypie with the slug for any Read the Docs
project.
However, RTD doesn't permit users to browse the website's directory tree via the URL: http://media.readthedocs.org/pdf/[project slug]/, get's me 403 FORBIDDEN! At least for project CookieCutter.
For security reasons, many websites do not allow you to browse directory listings on the web server; hence the 403.
Anyway, I guess you were looking for these:
https://media.readthedocs.org/pdf/cookiecutter/latest/cookiecutter.pdf
https://media.readthedocs.org/pdf/cookiecutter/stable/cookiecutter.pdf
Typically, it should not be necessary to construct this URL yourself. There is a link in the navigation bar of RtD. You just have to know where to find it.
Notice the 'Read the Docs' label at the bottom left of the page (together with the version indicator). Click it and a panel will open.
In the panel, you can select the desired version. The 'PDF' link navigates to the PDF file. The build system of RtD should automatically keep this file up to date with the documentation source.
Note:
for PDF and EPUB generation to be available, the RtD project:
must use Sphinx as its documentation generator; not MkDocs
must be configured to enable PDF and EPUB builds
I find the Read the Docs label that opens a panel with a pdf link preferable. However, if that isn't present, an alternative is doing a web search for it.
e.g., search for
readthedocs cookiecutter pdf
and the first result I see (as of 8 July 2020) is a link to the pdf: https://readthedocs.org/projects/cookiecutter/downloads/pdf/latest/
As of 8 Jul 2020, the cookiecutter readthedocs does indeed have expandable panel with the pdf link. However,
when I look at the readthedocs for pipenv, there is no ReadTheDocs clickable to open a panel. But if I search Google for
readthedocs pipenv pdf
the first result is a link to the pdf: https://media.readthedocs.org/pdf/pipenv/latest/pipenv.pdf
It appears that markermanager.js is no longer available on googlecode.com which has been closed. I have looked for an equivalent on Github, but so far without success. I can find marker-clusterer etc. but my code is built to run with markermanager.js.
Can anyone tell me where it has gone, please?
Following Google's move of the source, the new GitHub version can be accessed via jsDelivr (a content deliver network with no bandwidth limits that's focused on performance, reliability, and security) by using the following script urls (standard and packed versions):
https://cdn.jsdelivr.net/gh/googlemaps/v3-utility-library#markermanager/1.2/markermanager.js
https://cdn.jsdelivr.net/gh/googlemaps/v3-utility-library#markermanager/1.2/markermanager_packed.js
These urls specifically target the 1.2 release of the markermanager library - as covered in the following SO answer, in production you should consider targeting a specific release tag to ensure you're getting a specific release version of the script:
Link and execute external JavaScript file hosted on GitHub
Alternatively, you could download and include the library directly in your project for production purposes.
I've prepared and published on my website an installer package with the software I developed. The package is compiled and bundled into .exe file using WiX toolset and contains no viruses or malware. Next when I try to download the file I get a notification from Chrome that it's blocked due to malicious content.
Malicious content warning
I'm really upset that my customers being misinformed with such warning. Any ideas how to get around it?
Google created this page for developers - https://support.google.com/webmasters/answer/3258249.
Even though it doesn't say it on there, almost all auto-detection software will not block software that is digitally signed (and there is no bad reputation associated with the signing certificate).
If it's a simple file, just upload it to Google Drive or DropBox, and generate a public link for it and then share it on your website.
You can also shorten that link, if your application provide this service, or via goo.gl, in order to view clicks' count.
If any developer come across this issue, I manage to resolve it by streaming the downloadable file instead, via different URL (which doesn't have the file name and its extension with file's full path on your hosting).
Doing so by manipulating the response header, will fix the issue.
Here is a useful link about streaming a downloadable via php script
I would like to develop a browser plugin/extension (I'm not sure how they differ) for a particular (possibly new) file type. To be very explicit, I would like to visit a file, "foo.org", using my browser in something like Drop Box or Google Drive and have the browser treat the file as Emacs would treat an org-mode file. Eventually I would like to develop a full Emacs plugin/extension and be able to configure the browser to handle files with this plugin/extension based on the file extension or a file grokking heuristic.
Any solution that I develop will allow the editing to take place directly in the browser's tab area, i.e. a seamless solution (as opposed the useful but seamy Edit with Emacs solution referenced below). In the same way that Chrome recognizes a spreadsheet or word document and invokes the appropriate Google Docs tool, I would like to get an Emacs-lite editor handle the foo.org file. Another way to ask the question is: how do Google Docs tools get invoked within Chrome and perform the associated editing task. And are these tools open source?
You should consider building on Ymacs which is an Emacs-like editor in the browser.
For browser extensions, there is an experimental downloads api. However, it doesn't let you monitor downloads at the moment. This is planned for the future:
In the future, you will also be able to monitor and manipulate downloads.
However, you can probably just use some JavaScript and replace all links to *.org files with links that open in a tab running Ymacs. This should have the same effect--clicking a *.org link will open it in a new tab.
Take a look at content scripts and the tab api for documentation on how to inject a script into every page and how to open new tabs.
Take a look at Edit with Emacs , it should help you get (at least) part of the way there.