When I first announced pressfs I knew that write support was going to come up as a requested feature. As I mentioned in that post, before I made the initial release I’d already been working with write code. After more testing and code clean up I’ve updated pressfs to version 0.2.0, which has (very) limited write support.
And by limited, I mean really, really, really limited.
There are exactly two things that you can edit using pressfs in version 0.2.0: post content and a the url value for a user account (under contact info). Example paths for these looks like:
/var/wp/users/LOGIN/url
/var/wp/posts/POSTID-POSTNAME/content
I knew that post content was something people wanted to be able to edit, and adding another field that wasn’t related to posts made me think about how to properly abstract the code that determines which files are writable.
While I’ve tested this repeatedly against my dev install of WordPress, I can’t stress enough that you need to be careful. Read only is pretty safe, with no real way to mess up your WordPress install. Now that we are venturing into the write waters the code needs more people to test it before I’d consider it safe.
Now, with that out of the way, go give this a try – the pressfs code is available on github. Creating a new mount point is easy enough, and I recommend using a non-root account to do it. If your uid is 3000 it is as simple as:
python pressfs.py /var/wp/ -o uid=3000
And if you do find a problem, use the -d option to have pressfs run in the foreground, it will display filesystem activity and python errors.
6 replies on “pressfs – Dipping a Toe into Write Support”
I just installed this on a test site. Going to the mount directory, I see the 4 main dirs: categories, posts, tags and users, but they’re all empty.
Console output:
>> WP REQUEST : http://mysite.com?pressfs=1&call=get_post_list
Traceback (most recent call last):
File “pressfs.py”, line 306, in readdir
posts = self.wp_request( ‘get_post_list’ )[‘posts’]
File “pressfs.py”, line 452, in wp_request
‘data’ : simplejson.loads( content ),
File “/usr/lib/python2.7/dist-packages/simplejson/__init__.py”, line 384, in loads
return _default_decoder.decode(s)
File “/usr/lib/python2.7/dist-packages/simplejson/decoder.py”, line 402, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File “/usr/lib/python2.7/dist-packages/simplejson/decoder.py”, line 420, in raw_decode
raise JSONDecodeError(“No JSON object could be decoded”, s, idx)
simplejson.decoder.JSONDecodeError: No JSON object could be decoded: line 2 column 1 (char 1)
unique: 254, error: -22 (Invalid argument), outsize: 16
Ouch, simplejson didn’t like the text your site sent back. Try adding this
print ">> JSON : ", contenton line 450, which would look like:print ">> WP REQUEST : " + req_url
http = httplib2.Http()
resp, content = http.request(
req_url,
'POST',
urllib.urlencode( post_vars ),
headers = req_headers
)
print ">> JSON : ", content
That string is likely to be quite long (depending on how many posts you have), so make sure your terminal buffer is cranked up. From the error you mentioned the invalid JSON is right at the beginning of the string.
Ah, I had WP_DEBUG on:
Notice: Undefined property: PressFS::$ID in /home/lomo/tweets.scribu.net/wp-content/plugins/pressfs/class-pressfs.php on line 33
{“_is_error”:false,”_error_msg”:””,”users”:{“scribu”:{“id”:”1″,”login”:”scribu”,”nice-name”:”scribu”,”email”:”scribu@gmail.com”,”url”:””,”registered”:”2010-10-06 22:32:56″,”display-name”:”scribu”,”first-name”:””,”last-name”:””}}}
A perfect example of why preventing notices is important. 🙂
If I disable WP_DEBUG, it works ok.
By the way, for those that are wondering how to stop the program, I found this command works pretty well:
sudo umount ~/your/mount/point
Nice catch! I usually have WP_DEBUG turned on for my dev instance, I must have turned it off at some point. I’ve pushed out a fix to github, so you should be able to give this another try.
Yep, thanks. Openend Issue #1:
https://github.com/josephscott/pressfs/issues/1
There definitely needs more experimenting around different ways to structure the data. As you mentioned in the issue linked above, sites with thousands and thousands of posts would benefit from a more hierarchical structure.