When setting a record in the bolt-cms, there are multiple options for the status. What are they all, and what do they do? The documentation is not very clear what they are and what they are used for.
The current status of this record can be either: published, depublished, held, draft or timed.
published: a record has been published.
depublished: this content should not be accessible, but still not deleted. Available since Bolt 4.
held: this content should not be accessible, but still not deleted.
draft: when a record is not ready to be published yet because it is unfinished. This is the default status for any contenttype that does not have a default_status setting.
timed: used in combination with the Publication date field to publish a record in the future, or to have a record be published for a certain duration.
See also: https://docs.bolt.cm/4.0/contenttypes/intro#the-structure-of-a-record and https://docs.bolt.cm/4.0/howto/resource-contenttype#default-publishing-status
Related
I'm trying to set up a custom content type in Bolt so that only the owner can edit their own record. i.e. to stop users editing each other's records.
I don't seem to be able to get the right combination of permissions in permissions.yml though.
Using:
contenttypes:
mycustomcontenttypes:
edit: [ owner ]
in the content-type-specific permissions lists all of the mycustomcontenttypes on the overview page when I'm logged in as an account that owns a subset of the records, but none of the records I own have the title wrapped in a link leading to the edit page and the "Actions" menu does not have the "edit" option.
I would have expected the "owner" role to exist in order to give owners permissions relating only to their own records - surely that's the point of that role?
Is it therefore possible to set my custom content type such that (outside of superusers like root, admin etc) only the owner can edit their content record?
I have got this error of the maain page. How to fix it?
http://www.hippomocks.com/Talk:Main_Page
The revision #0 of the page named "Main Page" does not exist.
This is usually caused by following an outdated history link to a page that has been deleted. Details can be found in the deletion log.
According to Mediawiki:
Database inconsistencies occur when, for example, primary keys stored in other fields no longer point to a row that exists. This can happen after a database import ends prematurely, for example. In that case, page.page_latest might point to a revision that hasn't been imported, and users trying to read the page might get an error message stating "The revision #0 of the page named '[page name]" does not exist. This is usually caused by following an outdated history link to a page that has been deleted. Details can be found in the deletion log."
The maintenance script findAnomalies.php can be used to find missing revisions. From CLI on your server, cd to the maintenance directory in your Mediawiki directory and run the script. e.g.:
cd /var/www/html/wiki/maintenance
php findAnomolies.php
And try some extra stuff
The error message you get sounds like in the page table, the entry of the according page points to a non-existing revision. This might be fixable by running the maintenance script attachLatest.php. This should make the page point to the newest revision again. This would be what I would try first.
If that does not work and you in fact want to delete the page, I would try running the maintenance script nukePage.php. This script allows you to permanently(!) delete a page from the database. Afterwards you can use the script purgeOldText.php to delete unused rows from the text table.
However, note that your database currently is in an inconsistent state; although the scripts I mentioned were partly written for situations of brokenness, there is no guarantee that they can solve this.
I am integrating with the v2 Box rest api from an iOS app.
When I upload a file I cache it's modified date (as reported by Box in the return JSON)
Sometime later, I request the folder contents and check the modified date on the file (to see if it's changed since I last uploaded.) Depending upon how long I wait, the modified date changes - wtf!!!
If I request the folder contents immediately (msecs) after upload then the modified date is as it was after upload. If I wait 3 or 4 seconds then the date changes (by 1 second typically.)
Anyone from Box know why this might be - and how to fix it?
I don't know the answer to your particular question, but this caught my eye:
I ... check the modified date on the file (to see if it's changed since I last uploaded.)
If you're primarily concerned with detecting changes, then you might instead consider using the etag or version properties of the file object. They are designed for exactly this purpose.
After using a particular interwiki link for a while on my wiki (Mediawiki 1.15.1), the other wiki changed its domain name, and I'd like to update my interwiki links. I changed the URL in the mw_interwiki table, but the links aren't updating.
I have tried adding "?action=purge" on the page with the links. I do not appear to have $wgInterwikiCache set in my LocalSettings file, and the mw_transcache table has no rows in it.
Is there something else I need to do to trigger an interwiki URL update?
EDIT Time solved this problem; after a few hours the links updated, so it's probably a caching issue. Not sure what process would be best to force a cache break if ?action=purge doesn't do it, though.
Using version 1.4.1 of Extension:Interwiki (on MediaWiki 1.20.2), I had the same problem. Even after deleting the interwiki entry, page previews continued to use the previously-stored value.
Upgrading to Interwiki 2.2 20120425 caused my next interwiki edit attempt to fail, but I was able to delete the entry and recreate it; after that, the links finally updated.
Use Extension:Interwiki to do the change. It will update the links instantly.
I suspect that one of the limitations of running a static site is that the administrator has to be at the helm when he wants a post to be published. I'm looking for that suspicion to be validated. Is there a method I haven't discovered?
Set the site.future option to false on the _config.yml file.
Then set up a cron task in your server to regenerate your blog every day (or hour, whatever you fancy).
Posts set up in the future will be automatically published when the correct date is reached.