I work on an internal company wiki (so I can't provide any links), but I'll illustrate my problem as best as I can.
Problem: When I insert the wiki syntax to display a widget, it produces this instead:
Allows wiki administrators to add free-form widgets to the wiki by editing pages within the Widget namespace. Community-contributed widgets can be found on MediaWikiWidgets.org
Widgets I'm using:
Google Spreadsheet
Google Calendar
Google Document
I've followed all of the instructions as described on those three pages. I've also installed the widget extension (1.0) as needed. Note that when viewing the "Special:Version" mediawiki page, it displays this as the description for the widget:
Allows wiki administrators to add free-form widgets to the wiki by editing pages within the Widget namespace. Community-contributed widgets can be found on MediaWikiWidgets.org
I'm in the process of confirming the folder permissions currently used by our server, to ensure they match those as required by the widget extension, though I assume the permissions are correct. The PHP and MySQL versions being used are adequate for both MediaWiki and the Widget extension.
Did you remember to git init the submodule?
cd Widgets
git submodule init
git submodule update
Related
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
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
I created a repository for hosting a blog on github.Is there any way that I can create more to host multiple blogs?Am I limited to just one repository for hosting(since username.github.com can only be used once?)
You can have one site published to https://<username>.github.io by publishing to the master branch of a repository named “username.github.io” (substituting your actual username).
You can also have an additional site per GitHub project published to https://<username>.github.io/<project>. Project settings let you choose which branch and directory to publish.
A better description is available in the GitHub Pages documentation, including options for using custom domain names.
(since April 2013, all username.github.com are now username.github.io)
No you are not limited, it is possible to have multiple GitHub Pages sites within one account. Create another GitHub repository and push your site files to the gh-pages branch. This would result in the site being hosted at tshepang.github.io/repo-name
Now, push another file "CNAME" to the same repository and branch and fill it with movies.tshepang.net. Log in to your DNS host and add the CNAME to point to "tshepang.github.io" (just like the original site).
This would allow you to have seemingly two different sites on different domains. This would not work for having two or more sub-domains within github.io itself.
There is a possibility to host multiple pages within the same repository having sub-pages if you are fine with code duplication.
The latest version of my website is hosted on http://username.github.io/REPONAME
This is a screenshot of the structure of my root repository where I host the latest version of my website:
Inside folder "2.4.0" I can host a previous version of the same page ,which is then reachable at: http://username.github.io/REPONAME/2.4.0
This is the structure of the folder 2.4.0:
Using this methodology of sub-pages within a main page, you can host multiple sub-pages within one main page.
You can only create one user or organization site for each GitHub account. Project sites, whether owned by an organization or a user account, are unlimited.
GitHub Pages sites
There are three types of GitHub Pages sites: project, user, and organization. Project sites are connected to a specific project hosted on GitHub, such as a JavaScript library or a recipe collection. User and organization sites are connected to a specific GitHub account.
To publish a user site, you must create a repository owned by your user account that's named <user>.github.io. To publish an organization site, you must create a repository owned by an organization that's named <organization>.github.io. Unless you're using a custom domain, user and organization sites are available at http(s)://<username>.github.io or http(s)://<organization>.github.io.
The source files for a project site are stored in the same repository as their project. Unless you're using a custom domain, project sites are available at http(s)://<user>.github.io/<repository> or http(s)://<organization>.github.io/<repository>.
The publishing source for your GitHub Pages site is the branch and folder where the source files for your site are stored. If the default publishing source exists in your repository, GitHub Pages will automatically publish a site from that source. The default publishing source for user and organization sites is the root of the default branch for the repository. The default publishing source for project sites is the root of the gh-pages branch.
I found a workaround if you don't want to make separate repositories for your different sites but just want to host them. In your io repo, create an index.html file on your master branch that acts as a table of contents linking to your other sites(subDirectories) index.html files. The username.github.io master branch seems to be the landing page that enables the hosting, so if it doesn't see an index file linking out to your separate projects, it won't register your subdirectories. After this all you need is the URL to whatever project you want to view. The io basically behaves like a giant single website with all your separate projects on it. Of course, if you would rather have separate repositories, gh-pages is the way to go.
Today I created another site and rather than creating branch gh-pages I have configured the master branch in a repository setting --> GitHub pages section select Source as master (or any other branch you want). You will get site link in the same section, in my screen shot I have removed site link.
This works, but ssl is still something I need to figure.
In my case GoDaddy is where my domains rest (url1.xyz), with nameservers pointing to Cloudflare. Then in Cloudflare the A records points to Github Pages. This is website 1 live, running fine. For website 2 I create a subdirectly in my gh-pages repo with website 2 files e.g. url1.xyz/static/website2/ - Then I create a subdomain in Cloudflare (subdomain.url1.xyz). Then create a page rule (url forward) from the subdomain to the subdirectory containing the 2nd website e.g. subdomain.url1.xyz >> mask forward >> url1.xyz/static/website2/ .. Then in GoDaddy I can configure url2.co.uk to mask forward to subdomain.url1.xyz , which presents website 2 e.g. url1.xyz/static/website2/
Just to add to the above. With one github user account(https://< username >.github.io) we can still have multiple static content websites hosted with different custom domains (Eg: domain1.com, domain2.com, domain3.com)We can just create a new repository for each domain and point the A record to github pages IP and CNAME record to < username >.github.io
You can create multiple blogs in your github account.
One repository can be created under your username. Push your code to branch gh-pages and you can see the site on <username>.github.io
Another one can be created under your organisation. For this you will have to create your organization first. Create a new repository under this organisation and push your code to gh-pages. You can see your site on <organization-name>.github.io
You can also create for each of your project and the site will be available on <username>.github.io/<repository>
Please refer this for more information on github pages.
I am trying to add extra buttons for my wiki editor page and I came across to this page:
http://en.wikipedia.org/wiki/User:MarkS/Extra_edit_buttons#Simple_Install
In the simple install section, I need to add extra code in monobook.js.
However, I cannot find monobook.js in my wiki folder. Can anyone give me some direction?
The "simple install" you linked to is for Wikipedia users who want to enable the gadget from their personal script file.
The correct topic would be #Installing XEB on your own Wiki, however I don't fully agree with that (importScript is deprecated, for example). Your alternatives are:
let your users just import the script from //en.wikipedia.org/w/index.php?title=User:MarkS/extraeditbuttons.js&action=raw&ctype=text/javascript. That's a possible XSS risk, but imported userscripts always are. Bonus: The will always get the latest version.
copy the script, the css and the images to your domain - which means you are in charge to maintain them. You could locate them anywhere in your server's file system, on a wiki page in the MediaWiki: namespace (only admins can edit) or on a user subpage that ends in .js (only that user and admins can edit). The last one was recommended in the help file, but I suggest not to use User:MarkS for that. Ensure nobody whom you don't trust could log into that account.
Then promote that location to your users, so they can import the script from there.
Even better: Install the Gadgets extension and migrate the script to a gadget, which users can easily enable in the settings.
Notice the script is deprecated and might not work with current MediaWiki versions. It depends heavily on script loading order, which needs some hacks to integrate well with the ResourceLoader.
See also Manual:Interface/JavaScript; there are similar customisations at Manual:User group CSS and Javascript and Manual:Page customizations.
The page you linked to talks about a user's monobook.js, which is a page called User:UserName/monobook.js.
If you want to do the same for all users on your wiki, you can use the site-wide monbook.js, which is not a file, but a page called MediaWiki:monobook.js.
Keep in mind that those scripts only apply if you're using the Monobook skin. If you want to have some script for all skins, use User:UserName/common.js or MediaWiki:common.js.
I am currently using MediaWiki as a documentation website, with login authenticated by LDAP.
However, we have hit a snag. Certain pages contain sensitive information. For example links that say "click here to log in". I would like to be able to protect certain pages from being edited by just anyone. I would like to allow certain groups of users (like employees) to edit those pages.
How do I set up page protection by group in MediaWiki (if it is possible)?
This is well-covered in the MediaWiki docs:
In addition the page protection options Andy Lester linked to you can also setup site wide protection against account creation and anominous editing. See MediaWiki Manual:Preventing access