I find the Bookmarks feature really useful since I find myself in many different locations and on different computers. So I collect a large number of bookmarks.
To help me organize my Bookmarks, I'd like to request a new "Folder" feature in Bookmarks so I can group related Bookmarks together. I'm attaching a picture to help explain this concept. This concept is very similar to how Firefox and Chrome organize bookmarks.

I should probably mention I'm using OwnCloud 5.0.5 on OpenSUSE 12.2 x64 LAMP setup, and am brand new to OwnCloud.
Thank you,
Craig
+1
I'll work on this on the next couple of days.
So far it needs an schema change (add column parent, to have a hierarchy structure) and, on the frontend, may be jsTree (http://www.jstree.com) or similar, on the sidebar (leftcontent).
Thank you, this will be useful to get around the Bookmark 10 Tag display limit which currently exists. I already have over 20 tags. I hope migration effort for current bookmarks / Tags into the new format will be easy / painless / trivial.
I run MySQL backend (Ver 14.14 Distrib 5.5.28, for Linux (x86_64) using readline 6.2) with the latest release OwnCloud 5.0.x frontend on OpenSUSE 12.2 / 12.3 x64 accessing from both Linux (3.4.33-2.24-desktop / 3.7.10-1.16-desktop ) and Windows (7 and XP) based Thunderbird / Lightning, Firefox, and Chrome / Chromium.
If I can help, please send a message.
I just added a very basic support for folders. There are some limitations still, but should be fixed in a few days.
Currently it supports importing from FF and Chrome (haven't tested on others) preserving folders and order.
Limitations:
If somebody want to test it out and give some feedback that would be greatly welcome. Just clone my fork and checkout the branch hierarchy.

Ok, really feeling like a newb...
Rather than tamper with my working server, I set one up on my workstation (Neptune). I installed OC 5.0.10, imported my bookmarks from the server and verified everything worked... it did, bookmarks displayed, etc.
Then I executed
neptune:/srv/www/htdocs/owncloud # git clone https://github.com/asphxia/bookmarks.git
Cloning into 'bookmarks'...
remote: Counting objects: 11568, done.
remote: Compressing objects: 100% (1728/1728), done.
remote: Total 11568 (delta 5683), reused 11489 (delta 5605)
Receiving objects: 100% (11568/11568), 1.34 MiB | 637 KiB/s, done.
Resolving deltas: 100% (5683/5683), done.
And looked again...

The original looked like this...

So, what did I do wrong?
And what do I need to do to correct this?
Craig
You probably didn't do anything wrong. I'll checkout what could have caused that.
Thanks for the feedback.
I can't repro the error :/ Did you checkout the branch hierarchy?
git clone https://github.com/asphxia/bookmarks.git && \
cd bookmarks && \
git checkout hierarchy
Just tried your suggestion. Same result as before.
neptune:/srv/www/htdocs/owncloud # git clone https://github.com/asphxia/bookmarks.git && cd bookmarks && git checkout hierarchy
Cloning into 'bookmarks'...
remote: Counting objects: 11568, done.
remote: Compressing objects: 100% (1728/1728), done.
remote: Total 11568 (delta 5683), reused 11489 (delta 5605)
Receiving objects: 100% (11568/11568), 1.34 MiB | 191 KiB/s, done.
Resolving deltas: 100% (5683/5683), done.
Branch hierarchy set up to track remote branch hierarchy from origin.
Switched to a new branch 'hierarchy'
neptune:/srv/www/htdocs/owncloud/bookmarks #
I had to perform an rm -r bookmarks for your suggested command to succeed.
If you'd like, you can go to http://arno.com:81 and login as test/test. Maybe looking at HTML output will provide a clue?
I temporarily forwarded my web server for this URL to tunnel to my development machine.
Not sure why but the app keeps serving some old files. Some really old templates.
Tomorrow I'll install OC 5.0.10 to check against it (I'm running master).
Regards.
Ok, let me know when you're able to sort it out. From my end, I can afford to be patient.
I really like the idea that I can "import from FF and Chrome". Can this be made into a bidirectional "sync"?
Wish #1 - How hard would it be to put the Folder / Sub-Folder Tree in the "Related Tags" pane and have URL's displayed in the right pane, similar to the current Tag's setup? Vertical scroll bars available in both panes when content exceeds pane size?
Wish #2 - I like to store related URL information, like a utility account number and password for e-pay for sites which disable "saved" account information in your browser, phone numbers for support. Phone numbers are especially useful for cable companies that like to bury and hide this information on their site so customers will have a hard time finding this information, especially if the site moves this information to a new hiding place regularly, or internet access is down. This is related information (Notes) which I'd like to see if I do something like hover the cursor over the URL in the right pane. This sounds trivial, until you have 20 or more URL's with this kind of related information. Being able to easily copy/paste things like 30-digit account numbers from notes to enter into "required fields" is also useful. When things are going wrong, having this information at your fingertips is invaluable. Notes might look something like this:
Account Number:
00849833001234567890
Comcast Quality Assurance
888-565-4329 [1-1-2]
[email protected]
http://www.comcast.com
User Name: [email protected]
Password: Secre.....
Email Us: http://www.comcastsupport.com/com/email.asp
Phone: Call 1-800-COMCAST (1-800-266-2278). 24/7
I really like the idea that I can "import from FF and Chrome". Can this be made into a bidirectional "sync"?
There is no native way to do that. Unless creating an extension for each browser that communicates with ownClud.
Folder / Sub-Folder Tree in the "Related Tags" pane
That's the next step. The folder tree would be collapsible as well the "related tags" pane, otherwise it won't fit.
I like to store related URL information,
There is the description field. I took the liberty to remove it from the listing because it's not standard (you can't import or export this field, neither tags). I think that may be the bookmarks items can be "expanded" to show the description and such when clicked on a brief of the description.
If any one is still insteresting here's how it looks so far:

Only tested with SQLite. If anyone can grab it and test against postgres and mysql that would be nice.
Tried again with both git commands listed above. Getting the same results as last time. I'm updating "ownCloud 5.0.10 (up to date)"
Test account http://arno.com:81 setup last time should still be there if you want to look at output.
Image above looks great!
Hi asphxia checked out your fork

1.) Descriptions of the bookmarks are not displayed anymore
2.) I cannot figure out how to put them into a folder
3.) i cannot figure out how to create a folder
4.) it's still wasting lot of browser width
@craigarno i think you should move to apps/ folder before checking out
@roadfox Thanks for feedback.
1- It's not displayed anymore as I'll add a dropdown effect to display it. May be I can accommodate description and tags as it were before. But I think it leaves a small space for both.
2, 3 - Folder and bookmarks creation (inside a folder) are still in dev.
4- That's because when there are tags the full title isn't displayed. But I agree there is too much free space to use.
Regards.
@roadfox You are right, don't know why I didn't see that. All I can say is Duh?! Senior moment.
@asphxia 5.0.10 with revised Bookmarks App is installed using a duplicated OwnCloud MySQL db on a remote server. It appears to be working http://arno.com:81. Bookmarks are showing up and behave as they do in the released 5.0.10 app, minus descriptions.
Apps says I have Bookmarks 0.4 installed. Since 5.0.10 says Bookmarks 0.3, I think this means I'm running your new code.
I also see a problem when I scroll to the bottom and back to the top. Tag bubble images are scattered through the (title) column starting at about line 11. I also see from the database that Descriptions (description) are still in the database, just not presented.

@craigarno Thanks for the feedback. I'll look upon the tag issue.
Regarding the description I'll put it back and it used to. I thought as it's not a standard thing it wouldn't as widely used, but it seems it's actually very useful :)
App says version 0.4 on my fork only. I don't know if the app version will be bumped once the changes get merged (hopefully :)
Regards!
A thought or two on the description field.
Actually I was thinking on making the bookmark title the link and all the space left would be clickeable (except tags and edit buttons) and on click show the description (slide down).
This way there wouldn't be a need for an extra button.
Oops, didn't mean to post that yet (experiencing a few computer problems)... still working on the description idea.
But, yes, hiding the description field until it is requested might be a good thing. This will allow me to place login ID and password information in the description field and by default keep it hidden from view.
Another thought along these lines is to have a second "hidden" description field for sensitive information, like login, account #'s with CVV codes, etc.
On the TAG image duplication problem, it might be tied to the right scroll bar operation. I notice the scroll bar displays one size until I get to the bottom of my list, then it resizes to a larger page and more bookmarks are shown. It is after this resizing that the problem seems to appear. I don't know for certain they are related, however from what I've observed, I'd certainly consider that they might be related.
I think a second "hidden" would address a problem too punctual being out of the scope of a basic bookmark app.
I can think of a "show more" button bellow the displayed description layer that would expand the layer to show the full description, in case it's too long to fit. That idea can be implemented easily.
Regarding the tags issue, yes, the problem resides on how the tags are floated and dynamically inserted (fetched). When I get some time I'll push the fix (together with folder and bookmark creation).
I was thinking about the tag and folder issue and in my opinion to combine these two different organization structures are not that useful. I would suggest to concentrate on one of them. If we use tags, and that is what we actually doing, it is not necessary to also have a folder structure.You can group your bookmarks in tags as well as in folders. And the advantage to the tag structure is that you have a flat hierarchy. At the same time you can give a bookmark more tags to organize them more precise. What do you think?
I think it might be difficult to organise a huge amount of bookmarks only with tags. But more important is, that most of the browsers like Firefox use a folder structure. So import / export issues may be easier. For the user the "look an feel" is more similar. And there is a new Firefox-sync: Maybe in future the bookmark-app can access to the stored firefox-sync-bookmarks. That would be great.
any news?
Just wondering, is this feature still in development? I agree that folder support seems like a logical feature given that this is how most browsers manage bookmarks - the lack of this functionality makes it difficult for people used to organising bookmarks this way to adopt the app.
I second this. One reason keeping me from using the bookmarks app is it makes no sense to me without supporting folders.
+1 for the folder feature.
Without the feature the bookmarkapp is not as half as usefull.
+1
+1
+1
One more +1 :)
+1 ! will make syncing much easier
+1
If you'd all added your "+1" to the opening post, they would show up as a sum. That would be much more impressive – and make the comments much easier to follow. Right now, they are scattered across multiple (screen-) pages, and rather a nuisance :)
But apart from that: My "+1" is already present up there :stuck_out_tongue_winking_eye:
any progress on this?
+1 .. very important to make floggus able to work with folders .. https://github.com/marcelklehr/floccus
It's been 4 years since I left that post. I've been using the built-in Bookmark system provided by Mozilla Firefox and Mozilla Sync to keep all my bookmarks available on multiple systems.
The value I see in having bookmarks available in OwnCloud is having access to my BookMark data on public machines (Library), at work, a coworkers machine, or even on my own machine using a different browser, like Chrome or MSIE. In both work and public places sometimes the systems are so locked down that data can't be added and configurations can't be changed. Most of my book marks are related to design activity.
I'd still like to see this feature in OwnCloud, but I'm living mostly painlessly without. To be fair this is a thorny problem for the developer as it doesn't just involve OwnCloud. Does the author feel a need or motivation to complete this effort? If this is important to you, how can you support the effort?
Just an idea for an workaround ... Does someone know how to add in Firefox the foldername as a tag to all bookmarks in a folder?. Since nextcloud bookmark system supports tags this would be somehow like folders ...
@berndhahnebach thx for your post. So, correct, the bookmarks app makes intensive use of tags, and deliberately not folders. Because, folders are like tags, but less flexible, and make the UI difficult. To automatically take over folder names as tags when importing from other sources would be a good idea, I think.
@blizzz When realizing a sync step, this can get in the way though, as tags are not hierarchical. I've run into this issue with floccus: marcelklehr/floccus#5
My vision here is to use nextcloud/bookmarks, like most apps in nextcloud, not only as an app but as a storage backend that multiple apps/devices can sync to. However, most devices out there happen to rely on folders, or at least offer the feature, which makes it hard to sync them with this app.
I wouldn't advocate against tags. Don't get me wrong. I think tags are great, but if nextcloud/bookmarks is supposed to be useful to the normal user, who happens to bookmark things with the browser's native ui and perhaps wants to sync them, perhaps just wants to back them up, then supporting folders would be necessary, I think.
Let me be honest here: I use XMarks since... well since the beginning when they were called FoxMarks.
I could and would change to Firefox Bookmarks system because it has a LOT of advantages (specially in privacy) but there is one thing that keeps me from doing it: i can't access them anywhere.
Case: Many times i'm with a friend and want to show him that bookmark, or want to add a link he has to my bookmarks... how to do it???
If nextcloud's bookmarks could support folders and a a good addon for browsers existed (eg.: floccus - https://github.com/marcelklehr/floccus) then i could replace xmarks for something i trust, backup my bookmarks on my own server, access them anywhere, and add or remove bookmarks while being privacy aware...
it would be a cool world for bookmarks since it could be the cross browser solution and have the best of both worlds (Firefox & Xmarks)!!!
Please, consider it
@marcelklehr the problem with hierarchies are that they too often are random and could be just the other way around. With tags, you find them no matter the order.
I guess we can support one (or more) folder properties for syncing reasons. For the UI, however, I'd prefer to keep clicking on Tags "$Subfolder" "$Subsubfolder" "$Folder" (or any combinaton) instead of clicking along a fixed folder structure.
We can make it possible to mark tags as favorite, so that some important ones are always on top on the list (and in the same way perhaps also recently used tags).
How does that sound?
Since you ask, sounds good to me... what I hear is:
I think it will be important to be able to "edit" the path/folder information in a sync'ed bookmark.
i.e. /All Bookmarks/Bookmarks Menu/Utilities/PSE - Puget Sound Energy
Where the bookmark name is "PSE - Puget Sound Energy"
and the bookmark path is "/All Bookmarks/Bookmarks Menu/Utilities/"
I'd like some way to edit the path, even if it is just part of the Bookmark name and I'm editing one long string.
As we discussed earlier, I also need the Description field available. I use the description field to store Notes which go with the bookmark. Notes include; Company phone number, company Login/Account username/password, special pin numbers, anything else I need which is often very hard to find on the companies web site, or won't be available if I don't have an internet connection (like calling my ISP during an internet outage).
So what I hear is provide what is easy to provide now (no folder UI), and provide the rest as need and desire require.
The critical part of this will be the Sync interface. The Sync interface will get used by other applications, so it must be documented and not change. After reading Richard Newman's @rnewman comments in the Sync forum, sounds like a "transaction" based approach is most reliable. He has been saying interfaces like WebDAV tend to lose information which means some bookmarks never make it through the Sync process and represent "lost data".
There needs to be a rock solid Interface Specification for external Bookmark Sync. I'm sure this interface specification will include all kinds of things like; date, time, deleted status, name, URL, Tags, Keyword, Description, and at a lower level the mechanics of how this data is exchanged securely over a data channel, what handshaking occurs, what escape characters are used, packet size limitations, etc. I'm assuming the https channel will be used for sync. Any other ports/technologies will be blocked at some corporate installations.
What is done on either side of the interface is more up to the developer. The Sync Interface in the middle needs to be carefully thought out and nailed down.
For now, just get the OwnCloud UI and any existing data "sync" working as a proof of concept. My 2¢ and thoughts.
@blizzz I'm not sure i'm understanding you right (in the folder/subfolder subject) so, just in case, i would like to manifest that my near 3300 bookmarks (yes, it's been a few years adding to it, but their are VERY useful) are organized in, sometimes, 6 subfolders.
Loosing that priceless hierarchy would make me wanna beat someone... (and i do not believe in violence!)
I don't believe it's possible to correctly implement a bookmarks synchronization extension using the current WebExtensions bookmarks interface.
That rules out building a Chrome extension, and also Firefox 57+. You could build an unreliable one, of course, or take a different tack (e.g., owning the data somewhere outside the browser bookmarks store, which ruins the Awesomebar but gives you total control over syncing).
I'd also say that multi-writer syncing of structured data (like a folder hierarchy) is really hard, and will likely not be a fun project to get right.
@rnewman Thanks for you input!
I don't believe it's possible to correctly implement a bookmarks synchronization extension using the current WebExtensions bookmarks interface.
Can you elaborate, why you believe that?
I'd also say that multi-writer syncing of structured data (like a folder hierarchy) is really hard, and will likely not be a fun project to get right.
Multi-writer syncing of structured data is hard, I agree. However, there are solutions, like e.g. OT and CRDT.
I summarized many of my concerns in
https://bugzilla.mozilla.org/show_bug.cgi?id=1351897
Consumer-level APIs don't really expose the state changes that you'd need to do OT without a huge amount of work, roughly equivalent to maintaining your own data structures and trying to deduce changes from coarse-grained notifications. It's also not necessarily the case that your syncing system supports sending operations, or even deltas. OT works best when you have vaguely commutative operations, don't ever need to merge & dedupe two trees from scratch, and have mostly online operation. Bookmarks in a browser don't really fit.
@rnewman Your list in that bug is very enlightening -- a lot of good points. I'm very glad you jumped into the discussion :)
I agree that the current bookmarks API could do better in providing details on what exactly changed, but as you said you can still perform a diff, even if that's expensive. In a world where the choice is no sync vs. expensive, possibly less frequent sync I tend to take the latter.
The lack of transactions is a point that concerns me more, frankly. However, if you sync less frequently in a fixed interval instead of on every change, collisions are much less likely to happen -- you might not preserve every user intention if you move a folder from a to x when it's actually just been moved to b a few microseconds before, but at least the sync sites are consistent. Also, how likely is it for multiple extensions that move bookmarks around the place to be installed at the same time?
I agree that the current bookmarks API could do better in providing details on what exactly changed, but as you said you can still perform a diff, even if that's expensive.
This is one reason why transactions are important: without isolation at some level of the stack (explicit transactions, implicitly isolated batch APIs, serialized synchronous notifications…) you can't reliably compute diffs, either incoming or outgoing.
However, if you sync less frequently in a fixed interval instead of on every change, collisions are much less likely to happen
Yes, if you can guarantee that no local changes will occur while you're applying incoming changes, or while uploading outgoing changes, then you can avoid both collisions and inconsistency due to lack of isolation — this _is_ isolation via wall-clock serialization. However, it's not actually a guarantee — without true isolation and atomic changes there's always a chance of seeing a partial state in-flight — and at scale everything that _can_ happen _will_ happen.
you might not preserve every user intention if you move a folder from a to x when it's actually just been moved to b a few microseconds before, but at least the sync sites are consistent.
Consider what happens if you're trying to build a tree or perform an upload by repeatedly querying the local store. You might see a moved item twice or not at all, or miss a deletion, or whatever. Your results will be inconsistent.
This is really easy to get wrong in ways that aren't apparent when testing.
The only reliable way to do this kind of thing is by having storage itself do the bookkeeping.
Also, how likely is it for multiple extensions that move bookmarks around the place to be installed at the same time?
That would be wild speculation.
We've seen users who use both Xmarks and Firefox Sync, certainly. We've also seen potential issues interacting with add-ons such as Snooze Tabs, which generate synthetic bookmarks during browsing activity. There are add-ons that generate bookmarks as you browse.
But you can hit problems simply by having user activity overlap with a sync; add-ons just increase the rate of activity.
Also, how likely is it for multiple extensions that move bookmarks around the place to be installed at the same time?
That would be wild speculation.
Yep, that's true :)
you can't reliably compute diffs, either incoming or outgoing
What about browser.bookmarks.get(Sub)Tree, though? Afaict it spits out the whole tree as an object immune to modifications by the user or other extensions. In one call. This should be sufficient to do a safe diff, imo. Unless the implementation of that method isn't atomic, of course.
If I'm manipulating the live tree based on a diff I took against incoming data and something gets changed (other than the bookmark's id, if that is changed all bets are off), I can still apply my patches. The problems I get are "merely":
Overriding user changes of urls, titles or positions of items (perhaps even reviving deleted ones). No duplicates (unless two devices created the same bookmark concurrently). No deletions of newly inserted items.
So, I get collisions, but I have consistency with the server state for those items that I already know about.
In essence, my argument is: If you reduce the probability of collisions occurring by reducing the sync frequency, you can reduce the probability of overriding user changes that occur during the sync process. And, as you said, at scale everything that can happen will happen, however, you will never get an inconsistent state that the program cannot recover from. The worst case is, that the user looses an edit they made during sync, which in my opinion is better than having no sync.
The worst case is, that the user looses an edit they made during sync, which in my opinion is better than having no sync.
Not being much of a technical guy, but i agree that having some sync is better than none. Also, has a xmarks user, i can tell that when one forces a sync xmarks freezes the browser (only allowing you to move the sync window) to prevent changes during the sync process
What about browser.bookmarks.get(Sub)Tree, though? Afaict it spits out the whole tree as an object immune to modifications by the user or other extensions. In one call. This should be sufficient to do a safe diff, imo. Unless the implementation of that method isn't atomic, of course.
If it is atomic, you still need to capture the entire combined subtree of all changes, so for a move that might mean fetching and diffing the entire bookmarks tree each time.
Non-atomic local application isn't just limited to potentially losing local user changes. Content-based smushing, for example, relies on the local data not having changed since you last looked at it. Inserting records, too — what happens when you download five new records, and the user deletes the destination folder before you've inserted them all? You can't just abort and try again — the local insert isn't atomic.
You also need to detect local changes during the sync (both inbound and outbound phases), and ignore your own, otherwise you'll miss changes and your clients will diverge. This is really tricky to do with just observer notifications.
Like I said: this is hard to get right for the simple case, really hard to guarantee eventual consistency in the presence of races, and even harder to get right and still have acceptable performance for non-trivial amounts of data. Between two clients and a server you have a distributed transaction each time the user makes a change — the change has to commit in three places — and so without really noticing we're deep into distributed systems theory!
when one forces a sync xmarks freezes the browser (only allowing you to move the sync window) to prevent changes during the sync process
That's not a bad option. Well, it's bad for responsiveness, and we probably couldn't ship that behavior, but it certainly avoids most local races.
I just want to chime in on the "sync on change" vs. "sync on cron" topic:
My usecase involves adding bookmarks every now and then, which can be anything from 2 bookmarks a day up to 1 a month (often the latter). So for me "sync on change" is a lot more appealing as it doesn't cost that much (vs syncing every 20 min) in the long term and I get the change instantaneously.
Just my 2 cents 😄
(Sorry for my absence in this discussion lately...)
what happens when you download five new records, and the user deletes the destination folder before you've inserted them all?
Since the user deleted the folder anyway, what's the point in trying to insert the bookmarks? Since we're dealing with one user only, I tend to assume, they are aware of the newly inserted bookmarks at the other site, when they delete the folder.
You also need to detect local changes during the sync (both inbound and outbound phases), and ignore your own, otherwise you'll miss changes and your clients will diverge. This is really tricky to do with just observer notifications.
If I have an immutable snapshot of the bookmark tree, I don't need observer notifications, which are, as you said, hard to attribute to an actor, and I don't really need to watch out for changes while I'm manipulating the live tree, as those will only cause the edge cases I've covered above and will get picked up in the next diff.
@jkaberg Yes, onchange is always better than on interval. I can imagine finding a compromise between the two, where a change can trigger a sync, if it doesn't happen too often, but syncs also happen regularly, to poll the latest data from the server.
It's kind of funny that we're debating webextensions in here and how to add folder support to nc/bookmarks over here: https://github.com/marcelklehr/floccus/issues/5 :'D
Is anybody working on this at the moment? If someone is, can we expect folders in the near future?
Sorry for OT: In Windows 11 will be introduced new function. Microsoft from native filesystem removes folders, BUT there will be tags, which can be soo userfull for searching our data. Bookmarks are as files. We need some human organization in url mess :)
By "as files" you mean a file for each bookmark?
jumping late to the discussion. after reading all the replies since 2013 I can't seem to understand why wouldn't, a bookmarks api like this, have folder tree structure on the db. I mean, tags are fine. I don't know who uses them and how but on a web browser like chrome, firefox and safari, everything is folder based. even a filesystem is directory (folder) based or everything would be a mess.
I think this should be implemented along side tags.
a hack around would be to tag bookmarks like Amazon S3 does and some one suggested in another issue with tag: /path/for/bookmark
IMO Nextcloud Bookmarks is completely useless to users without having folders.
A Exported bookmarks.html in NETSCAPE! compatible Bookmarks format has more function than this.
If I want to search (for tags), i want to search (for tags), if i want to organize, i want to organize.
+1
desperately awaiting the support of folders, otherwise indeed it is almost useless (only a record of my bookmarks)
I use Floccus for FF + NextCloud Bookmarks on my android (AOSP) phone
+1
Overall I really like the bookmarks UI and the ability to access them with a browser addon. My own use requires folders and subfolders to organize information.
+1
Same here. Struggled about this and cannot understand why folders aren't supported. I really need this to organize my bookmarks.
+1
Since Xmarks.com is saying goodbye in about one month (May 1st), there will be a lot of people searching for alternatives!
Would be a good time to move this feature forward and present it as a viable alternative!!!
I completely agree that folders are needed in the Bookmarks App.
At the moment the closest thing are the 'tags' that floccus creates in order to store the information that'd be needed to recreate folders natively in browser bookmarks.
This is fine but it does mean that since there is no proper folder support, you can't store an empty folder. Empty folders can be very useful for planning, for arranging your bookmarks bar properly, etc...
Sorry but I insist on @Lantizia's request : folders are indispensable to organize bookmarks.
I have imported an html file containing all my bookmarks (which have been organized by folders) and what I see is a list of all my bookmarks, unsorted, unorganized, with empty tags. I have maybe 500 bookmarks... so folders are necessary, I would say "vital" for all people who doesn't start bookmarks from scratch.
Please could you integrate this feature ?
Thank you.
@prog-amateur Take a look at the floccus project, there is an open issue which is picking up traction where I've suggested they use something other than Nextcloud Bookmarks App (e.g. XBEL or JSON file stored on a WebDAV/Nextcloud/ownCloud server). This eliminates all the inflexibility that is currently an issue with this app.
To be honest I think I've fallen out of favour of using this app. If it wasn't for the fact it uses Nextcloud authentication... it may as well be a separate PHP development entirely, as it doesn't need WebDAV/files (what I see as the main point of Nextcloud) to work, it's entirely database driven and has a very strict ideology on how bookmarks should be done which just isn't reflected in the space we actually use bookmarks... browsers!
Almost to the day, it's now 5 years since this request was raised. The initial post was "upvoted" 20 times, and many more users added their "+1" in comments. Strange this issue still neither has an assignee nor a milestone – which suggests the team feels it unimportant. This is quite frustrating. It makes me feel that, though many users feel this feature important, we can discuss it as much as we want but won't ever see it.
Thanks to @marcelklehr for participating and insights, though! But after 5 years "staying around": is there some hope we will eventually see this feature?
@IzzySoft ownCloud & Nextcloud were mostly supporting Firefox Sync for a long time. But it has been deprecated in 2015. The new Firefox Accounts-based Sync solution has been quite a disappointment in terms of easiness to deploy in production. Maybe it has little changed now. Nextcloud Bookmarks is not a core feature, also bookmarking is an old concept that has been replaced by read-it-later solutions such as Wallabag, that are a step forward in the curation journey. Jan-Christoph Borchardt @jancborchardt from Nextcloud had the wonderful idea to start a collaboration between Nextcloud & Wallabag. Wallabag supports tags. I would advocate for going to this direction in the next two years, depending of the good will of the Nextcloud & Wallabag contributors. Considering the choice of Nextcloud by the German government, as a French supporter of ownCloud & Nextcloud since the beginning of the fight for data privacy, I can only applause and stay greatly positive for the future of Nextcloud.
@HLFH
Nextcloud Bookmarks is not a core feature, also bookmarking is an old concept that has been replaced by read-it-later solutions such as Wallabag …
Sorry, but I strongly disagree. Bookmarking has not been replaced by solutions like Wallabag – the two rather supplement each other. I use bookmarks for "permanent" storage, and "solutions such as Wallabag" for temporary items – as Pocket's original name suggests: "Read it Later". So for me those are two different concepts which both have their specific use cases. I use both, and I'd warmly greet Wallabag integration to Nextcloud. But to repeat what I wrote in my previous comment: That issue you've linked concerning Wallabag was opened more than 4 years ago (about half a year later than this one here) – and as this issue here, I see it's still open.
Considering the choice of Nextcloud by the German government, hopefully these two tasks get some more weight (funding?) as well – as both are important. And while bookmarking might be an "old concept", it is far from being "replaced" or outaged. Remember: Eating is an "old concept" as well :wink:
Sorry but this issue discussion is much too long and broad to be tackled. There are "Tags" in Bookmarks, which cater to the use-case of "group related Bookmarks together" which was mentioned in the original issue.
For any follow-up enhancements, please open new issues. And keep in mind it’s only few people (or one – @marcelklehr) working on it, so any help is welcome!
@jancborchardt it got that long because the issue was opened more than 5 years ago and not solved since. I don't see how the request to have bookmark folders is too broad. What makes it broad are just the different approaches suggested. So do you want a separate issue for each of those? Because the requested feature is pretty clear, at least to me. And its being missing is why most of us asking for it here cannot really use ownCloud/Nextcloud bookmarks.
I understand that there's "just a little processing power" (as you wrote, just one person working on it). But I'm very disappointed that, after 5 years waiting, the issue simply gets closed with that argument.
Again:
Sorry but this issue discussion is much too long and broad to be tackled. There are "Tags" in Bookmarks, which cater to the use-case of "group related Bookmarks together" which was mentioned in the original issue.
So it’s actually resolved. If there’s follow-ups → open separate issues.
Most helpful comment
@HLFH
Sorry, but I strongly disagree. Bookmarking has not been replaced by solutions like Wallabag – the two rather supplement each other. I use bookmarks for "permanent" storage, and "solutions such as Wallabag" for temporary items – as Pocket's original name suggests: "Read it Later". So for me those are two different concepts which both have their specific use cases. I use both, and I'd warmly greet Wallabag integration to Nextcloud. But to repeat what I wrote in my previous comment: That issue you've linked concerning Wallabag was opened more than 4 years ago (about half a year later than this one here) – and as this issue here, I see it's still open.
Considering the choice of Nextcloud by the German government, hopefully these two tasks get some more weight (funding?) as well – as both are important. And while bookmarking might be an "old concept", it is far from being "replaced" or outaged. Remember: Eating is an "old concept" as well :wink: