johnroper100 / dropplets Goto Github PK

Typography for the default template including lists, blockquotes, etc.

I think there should be some validation on the installation and settings screens which requires the user to enter their password twice and makes sure they match.

In the same vein as #59, if I enter my password wrong in the installation screen I then have to delete config-settings.php and re-install in order to reset my password. It would be much easier if we enforced the passwords to be identical to avoid typos etc.

How many of you use Dropbox? If so, would it make sense to make Dropplets a Dropbox only application? In other words, remove the setup and admin entirely and then simply use Dropbox for publishing and configuration. My thought is that this would completely eliminate all of the security issues that have been reported in the last few days as well as make the process for publishing and editing posts much more simplistic. I was planning on implementing Dropbox support anyway down the road, but I just thought I'd ask what everyone else thought?

Add a button within the "post" screen that would clear all cached post files.

According to several sources, SHA1 is a big no no these days:

http://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords

Probably should implement some tighter password hashing/security.

Pull #42 has implemented SHA1 hashing of passwords, however the hashed password is placed into the textbox and then used as a setting for a new password.

For example, a new installation of Dropplets with the password "hello" results in:

I then go to change my settings and the SHA1 password is stored in the text field.

So, assuming I ignore that, and just click the tick.

My password is now technically sha1(sha1("hello")).

While doing my first test, I noticed that having restrictive file permissions prevents the installation from working, which is expected, but instead of showing an error of some kind, it just reloads the setup screen with no indication of what the problem was.

my server not support this file then how install script without this file

When trying to upload a .md file via the drag & drop feature of the dashboard, I'm getting this JavaScript error in the JS Console:

Uncaught SyntaxError: Unexpected token < 

Even moving the file in the posts directory won't work. While it loads the title of the file, when i click (or navigate manually) to the url of that post, it will return a 404 error.

Accessing ./index.php before you've installed Dropplets results in the default installation screen, however accessing dashboard/index.php leads to the default dashboard login screen, placing this at the top of the file:

ini_set('display_errors', '1');
error_reporting(E_ALL);

Leads to the following errors:

We shouldn't be trying to include the configuration file before it's made, I'd suggest this be automatically directed back to ./index.php

A simple redirect after a new post has been published either to the post or to "home".

Implement a way to delete posts, possibly within single post pages. If the user is logged in, display a "delete post" link within the post meta (left).

...because it bugs me that it's sitting there in that file. I imagine it could just get run through a php function (base64 encoding or something) to encode/decode so what's stored in the config file isn't the raw password.

Using the new submit-settings.php as per de10a5b (a.k.a. the new .htaccess). The $blog_url now contains the following in the setup.php.

Please excuse the textbox, this is hidden by default, I've turned it on to show you the picture.

Due to the permissions issue, the .htaccess file is not always created during installation (and no indication is given). I'd suggest that the necessary rules for pretty permalinks be shown in the dashboard if the file doesn't exist.

If you don't want to show the rules in the dashboard, then maybe just include them in the Installation instructions.

Simple error styling when the wrong password has been entered within the post screen.

A simple dashboard that would allow the user to update the blog "config".

PHP $_SESSION isn't enabled on a lot of servers, meaning that Droplets will not work at all on those servers (at least the Dashboard). I'm going to propose that a cookie-based authentication system get built instead.

Is there desire to add Open Graph meta properties to this project? Could be added just like the Twitter Card meta elements.

I have it working on my own install but don't want to push it on anyone if it's not desired.

Supposedly this "just works" on most common servers. As per list of top 25 builds of servers, I tested this on six of the top variants. All returned 500 internal server error. I followed the directions to the letter, and copied the files up include .htaccess.

There's not even a discussion of the language this is written in! Why so vague? I'd maybe understand if this was a simple rails app… but it does work at all, and gives no directions as far as what happens next.

I cannot be the only person getting errors like this.

Working on a simple password hash within the new "config-settings.php".

I'm just wondering how I can add a new page...

Right now I have a directory, login, that has an index.php in it. I want to be able to go to example.com/login and view that index.php.
But when I go to example.com/login I just get a 404 page; I think Dropplets is trying to read a post called login.

So how can I add a page?

It seems that the new "Check Custom" function is setting "$stylesheet_dir" as "/template/custom/" regardless of their actually being a custom template.

I noticed last night as I installed a fresh copy of Dropplets that you can no longer use apostrophes in your site description or intro while filling in your information on the setup page. If you do, it'll return this error (on WAMP, anyways):

SCREAM: Error suppression ignored for
Parse error: syntax error, unexpected T_STRING in C:\wamp\www\dropplets\config\config-settings.php on line 7

Due to the lack of authentication on submit-settings.php, isn't it technically possible to change other peoples' Dropplets' information using a well crafted HTTP request?

So they don't do this: http://d.pr/i/P9ei

Should be easy enough to add to the css. I'm assuming that happens in the /template directory?

(this applies to Leeflets as well)

There should be an automatic update system of some kind. Would be awesome if it could pull directly from Github, along the lines of https://github.com/pdclark/WordPress-GitHub-Plugin-Updater

Seems like a reasonable thing to implement.

http://oembed.com/

There's currently no way to reset a user's password if they have forgotten it. Before the passwords were hashed this was easily remedied with a simple browse of config-settings.php, now if I forgot my password (understandable with a blog I don't update often) I need to go SHA a new password and edit the file.

I think having a means of resetting the password would be good, for example:

• Click "I forgot my password!"
• Generate random code, store it in a recovery file (bit like how we store settings at the moment.)
• Sends email with random code to $blog_email in config-settings.php.
• Clicking the link passes the code via $_GET, which is then checked against the recovery file.
• If the code matches, the user is prompted for a new password.

Get the following errors after submitting install:

Notice: Undefined index: header_inject in .../dropplets/config/submit-settings.php on line 36

Notice: Undefined index: footer_inject in .../dropplets/config/submit-settings.php on line 37

Warning: Cannot modify header information - headers already sent by (output started at .../dropplets/config/submit-settings.php:36) in .../dropplets/config/submit-settings.php on line 74

Using Chrome and PHP 5.4.4

Simple post category filtering via jQuery.

Links are not styled when they are outside <p> elements in the Simple template.
For example, when links are inside <li> elements.

Line 119 of templates/simple/style.css uses .post p a as a selector.

Changing that selector to .post a appears to fix this issue.

No pagination... just infinite scroll.

Meaning any commits people make could potentially lead to password exposure.

No need to always be regenerating them.

Ticketing it in Issues so that it‘s on the radar - I’ll probably hack on this myself.

refering to this twitter by jakewillsmith

@dropplets Any plans for a simple online editor? I think that’d make me fully switch.

You could easily implement that by using Ace.js and Marked.js. Ace.js for the editing and marked.js for the compilation of markdown to html so that you can preview the lost live.

I'm using them both in my new project (which is in a really early alpha stage) and seems like they work quite well.

ps: I would have tried implementing this for you but I'm currently suffering from tendonitis in both wrists so I can't do much, sorry :(

Anyone that have dropplets working on a nginx server?

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30

HTTP standard requests an absolute URI when doing header re-directs. Some browsers support relative re-directs but this isn't guaranteed; dropplets/config/submit-settings.php contains a header redirect which points to ../../; this should really be changed.

Need to clear the post cache when a post is updated.

How would we like to handle new themes? I'm imagining that we don't want to include a ton of different theme options w/ the base Dropplets install, right?

I've got a new theme I'm cooking up (based on the chevron shape). Should I create a new repo for it?

Same as "submit-settings.php", anyone with a little know-how could change your template on your Dropplets installation.

example: http://chrisreynolds.io/blog/

self-explanatory, really. If there's markdown in the first paragraph (I'm assuming), it gets read as plain text rather than rendering the styles the way it does in the single post page.

Dropplets should generate PHP files for posts instead of HTML from post uploads. This way, we can include PHP variables and functions in our post files and they will be parsed when a post is viewed.

minor issue but would be nice to see this handled more gracefully. If I go to mydroppletssite.com/posts, I get:

Warning: file(../posts/posts/.txt): failed to open stream: No such file or directory in /home/myusername/mydroppletssite.com/dropplets/index.php on line 189

Update Looks like this happens pretty much whenever a 404 page is displayed since it's trying to find the txt markdown file for that post (which doesn't exist)

Implementing a system that allows multiple posters might be useful.

Thoughts?

Need to implement some image post styling for the default template.

There may be a potential vulnerability with "publish.php" which could allow anyone to publish a post to a Dropplets installation.

The cached version is a nice thing but what about plain html, css and js at the frontpage as well? The only time PHP is needed is for inseting/generating new posts and for the rss.