A clean, Markdown-based publishing platform made for writers. Write together, and build a community.

Describe the bug

New posts not shown in Hubzilla

Steps to reproduce (if necessary)

Steps to reproduce the behavior:

1. In Hubzilla, add a new connection to a write.as account
2. On the write.as account, add a new post
3. Check that this new post is visible elsewhere (ex: from misskey), but not on Hubzilla

Expected behavior

I should see the new post in Hubzilla

Application configuration

Tested in qua.name instance Version or last commit: v0.9.1-49-g901bf14

In my actor, https://blog.dereferenced.org/api/collections/kaniini, I see:

"endpoints":{"sharedInbox":""}

This is obviously wrong ;)

this moves the unmarshaling of a remote actor out into a new helper which accounts for the possibility of a context being a list or a single entity. i.e. a string or an object.

basics tests are provided for both situations

also go fmt'd the file activitypub.go

during the course of working on this I found a missing string format variable in exports.go, in fixing that I also go fmt'd the file.

Fixes #100 This also fixes #116 by using the followers Inbox if SharedInbox is not set.

• [x] I have signed the CLA

Describe the bug

The markup

![Red dot](data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==)

Should show a red dot as an image.

It doesn't. Inspecting the generated HTML from the Markdown shows that the generated img element has no src attribute.

I think, but have not confirmed, that this is because https://github.com/writeas/writefreely/blob/32e99d00415c6e86a9536d9b824dcdf0b119270d/posts.go#L1368 does not include data: as a valid protocol.

Expected behavior

img element should be created with the correct src attribute.

ERROR: 2018/11/11 11:57:33 log.go:26: Rolling back collections INSERT: Error 1364: Field 'description' doesn't have a default value
ERROR: 2018/11/11 11:57:33 log.go:26: Unable to create user: Error 1364: Field 'description' doesn't have a default value

I had to manually change description varchar(160) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL to description varchar(160) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL DEFAULT ''

however after that it shows the same problem with privacy field. Either something wrong with my mySQL or with your schema.sql. Server version: 5.7.18-0ubuntu0.16.10.1 (Ubuntu)

I tried to upgrade to v0.12.0rc1

"db migrate" gives the error ERROR: 2020/04/19 17:16:57 main.go:121: migrate: Error 1709: Index column size too large. The maximum column size is 767 bytes.

I suspect this is due to my mysql being setup in utf8mb4.

This fixes federation with Mastodon instances that have Authorized Fetch turned on by signing the GET request to fetch the actor when a blog is first followed.

Closes T820

• ☑ I have signed the CLA

This pull request adds code that scans the text of each post to be published for handles of the type @[email protected], uses webfinger to ask ActivityPub endpoints about them, gets their inbox and actor IRI's and adds mention tags to the post. Finally it adds the users to the CC list of the recipients of the activity.

This works in pleroma but not in mastodon unless we set the object type to "Note" instead of "Article"

T627

Describe the bug

I'm running WriteFreely v 0.9.1 on my Scaleway instance with 2GB of RAM. It's a single-user federated instance with SQLite as backend. I'm managing it via systemd with the following service description:

[Unit]
Description=Write Freely Instance
After=syslog.target network.target

[Service]
Type=simple
WorkingDirectory=/home/groosha/writefreely
ExecStart=/home/groosha/writefreely/writefreely >> /var/log/writefreely.log
Restart=always

[Install]
WantedBy=multi-user.target

The only modification I made is replacing one of "letter-avatars" with a custom one to see a proper profile pic on Mastodon.

Symptoms

If I run WriteFreely for a long time (let's say, a month) without even touching it (no users, no new posts, nothing), it consumes almost all free RAM on server, causing other apps to have problems. For example, my Python scripts which are running as cron jobs and regular processes, raise some exceptions like RuntimeError: can't start new thread or vedis.cpython-35m-x86_64-linux-gnu.so: failed to map segment from shared object. Also running htop shows that writefreely process consumes ~60% of RAM: (notice that I'm running only one process, but htop shows all threads)

After I restart writefreely with systemctl restart writefreely everything gets back to normal: (here I enabled "tree" view of processes, showing that I have only 1 process of writefreely and others are most likely threads)

My bad I didn't write down Go internal stats from /admin page, I guess it would help a lot.

Expected behavior

RAM usage should depend on active users or API usage, not increase as the time goes by.

Application configuration

• Single mode or Multi-user mode? Single mode
• Database? SQLite
• Open registration? No
• Federation enabled? Yes
• Operating system? Ubuntu 16.10 (oops!)

Version or last commit: 0.9.1

previously the checks were explicit locations which does not work when using something like nvm to manage node packages and versions.

this checks for the executable and sets the script variable LESSC to the full path of the one found. if none was found the make command will error.

• [x] I have signed the CLA

When following my writefreely user [email protected] from friendica [email protected] I get the following error response upon writing new posts / updating posts in writefreely:

2020/04/10 22:51:59 Response: JsonLdException: [jsonld.SyntaxError]: Invalid JSON-LD syntax; @context must be an object.

From the json-ld spec it also seems that the context is supposed to be an object or a link to a jsonld file: https://www.w3.org/TR/2020/CR-json-ld11-20200316/#the-context

Describe the bug

Clicking on a HashTag throws 404 error

Steps to reproduce (if necessary)

Steps to reproduce the behavior:

1. Create a hashtag in a post, and publish post
2. Click on hashtag

Expected behavior

The expected behaviour via the writer's guide is that the user should be taken to a special page that shows all posts with the same hashtag. The document is being called correctly e.g. https://blog.neurodiversity-in.au/stephen/tag:Fediverse

Application configuration

• Multiuser
• mysql
• Open registration - Yes
• Federated - Yes

Version or last commit: v0.13.2 (tar file)

This replaces the CGO wrapped C SQLite from github.com/mattn/go-sqlite3 with the pure Go implementation of SQLite from modernc.org/sqlite. This should remove the need for CGO to build WriteFreely. That is you can do:

CGO_ENABLED=0 go build -v -tags='sqlite' ./cmd/writefreely/

I've tested that I can initialize a new database, and also that I can load and serve the web UI from a database that was created with a build of WriteFreely using the CGO SQLite. Also, the tag pages work, which suggests that the add-in regexp command works. However, obviously this could all use some more extensive testing by people with significant SQLite databases.

Motivation: With CGO SQLite removed, it should be possible to cross-compile WriteFreely without needing xgo or a C compiler setup. Not all OS and architecture combinations are supported by modernc.org/sqlite, but the list includes all the major ones. So this should make it easier to compile on a Mac and deploy on Linux, build binaries for all platforms using CI/CD, and so on.

• [X] I have signed the CLA

Describe the bug

When I'm writing in an RTL language at the editor screen, text direction is not set to RTL. But it has no problems with LTR languages. In other words, the user is expecting the text field to support bidirectional texts, but it doesn't.

Steps to reproduce (if necessary)

Steps to reproduce the behavior:

1. Go to the editor screen
2. Start typing in an RTL language (Persian, Arabic, etc.), followed by some LTR Paragraph.
3. You'll see something like this, which is disturbing.

Expected behavior

Adding bidi support is very easy, I assume. I just attached dir="auto" to the textarea. (Maybe there are some other places you should use this attribute. I don't know.)

Applications configuration

• Multi-user Mode
• Open Registration
• Federation Enabled

v0.13.1

Describe the bug

When you request a text file that does not exist, the HTML is not formatted and the server responds with 200 instead of the usual 404.

Steps to reproduce (if necessary)

Steps to reproduce the behavior:

1. Go to 'https://www.rant.li/(name).txt'

Expected behavior

WriteFreely should return a 404 and format the HTML.

Application configuration

• Single mode or Multi-user mode? Multi-user mode
• Database? [mysql/sqlite] MySQL
• Open registration? [yes/no] Yes
• Federation enabled? [yes/no] Yes

Version or last commit: v0.13.2

The intention of this Pull request is to make Writefreely interface translatable for any language easily. The only thing needed to do this is to add the language of the instance in the config.ini file, e.g. language = eu_ES and edit its corresponding PO file located in the locales directory. I'm not a GO developer and it might not be the best way to program it, but it works really well in a Docker container. I wish this could be a first step :)

• [x] I have signed the CLA

Hello,

Currently, the majority of the editor controls on the new post page do not work as expected when using a screen reader.

The actual text areas work great, except for images in some cases (see below).

For the pad editor:

As far as I can tell there should be 2 dropdown menus (one for draft/public), and another one for selecting the font. A third one should be present if a user has multiple blogs.

Here the edit field and the publish buttons are accessible.

The above mentioned controls, however, appear as links, without any indication of what they belong to or whether they are selected. Adding ARIA menu and selected attributes should establish a logical order for a screen reader.

Ideally, keyboard focus would be nice for complete accessibility, but just with some ARIA attributes these controls would be usable.

For the classic editor:

Some controls, such as the read more element appear as a clickable, these should have a button ARIA role.

I do not see controls to select draft/public state for the new post here.

Sometimes, the cursor gets stuck if an image is encountered, for example if one inserts a read more tag. I haven't tested the editor with inserted images, but it could potentially have the same happening.

For the bare editor:

This one does not seem to have controls, other than two links to the blogs and the posts of the current blog (I assume). In case the draft status can be selected, they are not visible to a screen reader here.

The word count is readable in all 3 views.

When editing an existing post, there is a new Edit metadata link, I'm not sure if this should appear for new posts as well. If so, it's not visible to a screen reader.

I am using 29c898867ac23ea0df794ac481b1c8b8522d6c84 to test, currently under MacOS Safari via VoiceOver.

I can test on more operating systems, if needed.

Thank you very much in advance for any work to make these editors more usable. Please let me know if there's anything else I can do.