You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/actions.rst
+1-1
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@
9
9
Custom Actions
10
10
==============
11
11
12
-
.. versionadded:: 3.4
12
+
.. versionadded:: 3.4.0
13
13
14
14
In analogy to Django's admin actions, you can define your |fb| actions and thus automate the typical tasks of your users. Registered custom actions are listed in the detail view of a file and a user can select a single action at a time. The selected action will then be applied to the file.
Copy file name to clipboardexpand all lines: docs/file_storages.rst
+1-1
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@
9
9
File Storages
10
10
=============
11
11
12
-
.. versionadded:: 3.4
12
+
.. versionadded:: 3.4.0
13
13
14
14
Starting with |fb| 3.4, you have the option to specify which file storage engine a |fb| should use to browse/upload/modify your media files. This enables you to use a |fb| even if your media files are located at some remote system.
Copy file name to clipboardexpand all lines: docs/settings.rst
+2-2
Original file line number
Diff line number
Diff line change
@@ -94,7 +94,7 @@ Versions
94
94
VERSIONS_BASEDIR (relative to ``MEDIA_ROOT``)
95
95
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
96
96
97
-
.. versionchanged:: 3.4
97
+
.. versionchanged:: 3.4.0
98
98
99
99
Directory to save image versions (and thumbnails). If no directory is given, versions are stored at the same location as the original image::
100
100
@@ -140,7 +140,7 @@ Extra Settings
140
140
SAVE_FULL_URL
141
141
^^^^^^^^^^^^^
142
142
143
-
.. deprecated:: 3.4
143
+
.. deprecated:: 3.4.0
144
144
With custom storage engines, saving the full URL (including MEDIA_ROOT) doesn´t make sense anymore. Moreover, removing this settings allows for easily replacing a FileBrowseField with Djangos File- or ImageField.
Copy file name to clipboardexpand all lines: docs/sites.rst
+2-48
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@
8
8
FileBrowser Sites
9
9
=================
10
10
11
-
.. versionadded:: 3.4
11
+
.. versionadded:: 3.4.0
12
12
13
13
As of version 3.4, the FileBrowser application is respresented by an object of ``filebrowser.sites.FileBrowserSite`` (in analogy to Django's admin site). FileBrowser sites allow you to:
14
14
@@ -22,50 +22,4 @@ The module variable ``site`` from filebrowser.sites is the default FileBrowser a
22
22
Backward Incompatibilites
23
23
-------------------------
24
24
25
-
The only thing that you need to pay attention to when migrating to FileBrowser 3.4, is the specification of your URL-patterns. URL-patterns are now associated with a FileBrowser site, that is, each FileBrowser site can have different URL-patterns. See :ref:`quickstart` for how to setup your URL-patterns.
26
-
27
-
.. Mutliple FileBrowser Sites
28
-
.. --------------------------
29
-
30
-
.. .. important::
31
-
32
-
.. In majority of cases, there's no need for seting up multiple instances of FileBrowser sites. It is a supported, but not very standard way of using FileBrowser. However, there might be a few good reasons to use multiple |sites|. For example, you want to allow users to upload/delete/modify files at a location outside MEDIA_ROOT or you have implemented some custom actions that should be accessible only to certain users. In these cases, having multiple |sites| can do the job.
33
-
34
-
.. Before you start including additional FileBrowser sites to your project, note that there will be always a **single** FileBrowser site associated with FileBrowseFields. This site, called the **main site**, is invoked, when a user clicks on the search button of a FieldBrowseField. If you use multiple |sites|, then the main site is the one with the instance namespace "filebrowser" (or the last deployed instance, if there is no instance named "filebrowser").
35
-
36
-
.. When creating a site, you can specify its instance namespace like this::
37
-
38
-
.. fb_site = FileBrowserSite(name="fb-site")
39
-
40
-
.. The default |site| ``filebrowser.sites.site`` has the instance name "filebrowser" and will be therefore the main site if you use it.
41
-
42
-
.. The Main Site
43
-
.. ^^^^^^^^^^^^^
44
-
45
-
.. Although it is possible to define MEDIA_ROOT and MEDIA_URL on per-site basis, the main site *must* have these variables equal to the global, default values given in ``settings.py``. See :ref:`settings` for the details about MEDIA_ROOT and MEDIA_URL.
46
-
47
-
.. Additional Sites
48
-
.. ^^^^^^^^^^^^^^^^
49
-
50
-
.. Any site, that is not the main site can have its MEDIA_ROOT and MEDIA_URL set to a whatever value you wish. In order to deploy an additional |site|, create the instance and give it a unique name::
The only thing that you need to pay attention to when migrating to FileBrowser 3.4, is the specification of your URL-patterns. URL-patterns are now associated with a FileBrowser site, that is, each FileBrowser site can have different URL-patterns. See :ref:`quickstart` for how to setup your URL-patterns.
0 commit comments