jacobwb / hashover-next Goto Github PK

Collapsed comments

Full comments + reply forms

Updated edit and reply icons

I am posting this here for comments and suggestions. This updated layout will be pushed along with the other (much delayed) changes. The HashOver 1.0 style will be ported as necessary to work with 2.0 and be made available in the style-sheets directory, however, the style will likely be deprecated at some point, maybe even as soon as the release of version 2.1.

Is this only on my end?

I see the if statement for $page-title = yes in javascript-mode.php but setting 'no' in settings doesn't do anything.

Cheers

This isn't actually an issue but don't know where else to post, please delete if you feel this as unnecessary...

Anyway, my 2 cents on making hashover even better:

• implement Ajax when commenting, would remove unnecessary page reloading on each new comment and make things look more sexy... something along the lines of this
  http://wordpress.org/plugins/wp-ajaxify-comments/developers/

Should perhaps be considered big priority if claiming to be a Disqus alternative?

• ability to also specify custom css instead of just custom html template, so it's easier to keep the changes when upgrading
• other stuff but it's getting late.

Cheers

This is a lot of work, but I'm currently in the process of removing table elements from the new comment form, also the reply form later.

I'm a bit confused by the 'is mobile' parts at line 419 and 442 in javascript-mode.php.

When are these called and what is displayed?

Sorry for the confusing title.

Been checking my logs and noticed naxsi blocking GET requests like this from google's bot

 "GET /hashover.php?rss=http://tapebrain.com/news/transformers-age-extinction-international-trailer/&title=Transformers:%20Age%20of%20Extinction%20fresh%20garbage%20%E2%80%A2%20Tapebrain HTTP/1.1"

I'm trying to figure out if I should whitelist this block, but am not sure what's going on exactly...

Do you perhaps have any idea on what's being called here?

The message for the main reply form keeps

style="display:none"

when submit is clicked

Currently, a user can smash the submit button without entering anything and it will reload the page.

This could be a potential security/performance risk?

Off course, one could protect the submit server-side, but it would be better to have some sort of validation check without reloading the page.

Since we're using pure JS this needs further discussion on what would be the best solution. Some quick googling seems to give solutions but I need to investigate further.

Some quick finds for reference:
http://sbpoley.home.xs4all.nl/webmatters/formval.html
http://stackoverflow.com/questions/10516122/how-prevent-submit-if-input-are-empty-with-javascript

Tries to load svg from gravatar thus throwing 400 bad request

Nice to see you implement this.

Just wanted to clarify and perhaps brainstorm further improvements on it's functionality.

Here's what I noticed when trying it out:

Click on like:

• displays 1 like and the Liked link appears. When it's clicked the like dissapears (if this is intended then perhaps make it say Unlike or something)
• However when I now click Like again it doesn't stay Liked after refresh
• Same goes for Dislike

In any case Unliking/UnDisliking breaks something

PHP Notice: Undefined index: HTTP_USER_AGENT in /hashover/scripts/setup.php on line 45

if (preg_match('/(android|blackberry|phone)/i', $_SERVER['HTTP_USER_AGENT'])) {

An isset check should help:

if (isset($_SERVER['HTTP_USER_AGENT']) && preg_match('/(android|blackberry|phone)/i', $_SERVER['HTTP_USER_AGENT'])) {

I know we talked about this somewhere down the line.

So the way it works now is intentional?

It would make more usability sense if it could be used across the website showing latest posts in general from all the pages.

Something like:

• there's an additional general JSON or XML file
• user makes a post and link to it is written to the file
• Latest widget parses the comments

Been checking my results on tools.pingdom.com and noticed this

Remove the following redirect chain if possible:

http://tapebrain.com/hashover/scripts/avatars.php?format=svg&size=45
http://tapebrain.com/hashover/images/svgs/avatar.svg

Any idea if we can avoid that?

I'm having a weird bug and I thought it was something on my end but I can't figure it out.

Here's a test page
http://tapebrain.com/cmtest.php

In Chrome I can't submit the comment, works fine in Firefox and IE. Would you mind testing it on your build so I can narrow it down?

First I thought it was something with permissions but since it works fine in other browsers I'm totally confused, I also tried clearing cookies etc. same result

EDIT: tried submitting empty form on your website, same problem (I get the popup for not receiving notifications without mail and then nothing happens)

Currently comments may only be liked, and then unliked, a comment's popularity is decided only by people who like the comment (as to agree with it), people who dislike a comment (as to disagree with it) have no power in its popularity. Adding functionality to dislike comments along with liking them would allow Disqus and Reddit-style voting, where comments are sorted in descending order by the number of likes minus the number of dislikes.

Using CSS, anyone should be able to choose how to present the Like/Dislike functionality to users, whether it's presented as "Voting" or Thumbs Up/Down.

I had some ideas on how stuff like this could be implemented but am wondering should this even be a topic for the current branch?

Example idea:

• once a new comment is written, also write the same comment in a file that stores cc 5-10 comments.
• we can then use the file to e.g. display a separate widget somewhere with the latest posts

Just wanted to throw a brainstorm out there, close or move if needed

I currently don't have a local environment to test this but was wondering if something like this has crossed your mind?

http://www.fusionswift.com/2010/05/php-concatenation-benchmark-comma-vs-period/
http://www.electrictoolbox.com/php-echo-commas-vs-concatenation/

From what I've read around comma offers potential speed increase.

In any case if you have/will consider this change I've no problem personally replacing them if it's a hassle :)

Well this is weird

Notice: Undefined index: password in hashover/scripts/writecomments.php on line 96

On trying to post a comment. Works fine on my test page but get's broken on any one of my websites pages. Same with or without var password_on = false

There should be a specific thread for this?

I made a quick(subject to change/approval) icon collection on fontello which should cover all the png images
https://drive.google.com/file/d/0B2EsjStXMIFZdlNWYlNDQl9IN1k/edit?usp=sharing

You can drag-drop it on fontello.com and see on their website.

If you don't think it's wise to implement these or similar in core, perhaps then as part of the styles folder, so a theme css can easily pull them out. I would have no problem maintaining these as necessary.

Though, as per the links I posted in the other thread, browser support really shouldn't be an issue. Do you really need to worry about IE6 and Firefox 3?

Pros:

• less html requests, only 1 file is loaded for all icons (even the default avatar can be easily made with this) which is 5kb at most for svg, 4kb everything else
• looks sexy everywhere
• easy to change colors depending on theme etc.

Cons:

• can't use easily as input background

Why not use this and make a fallback css with .png's and maybe even fallback option for default avatar if some archaic browser compatibility really is an issue.

For those who want to make their own themes they can easily remove the font-face and not load this at all...

I somehow don't get it to work. To save bandwidth, I like hashover only to be loaded when the #comments div appears on the screen. I am using the jquery appear plugin for this purpose:

$(document).ready(function(){
    // load commenting only if it becomes visible in screen
    if( $('#comments').length>0 ) {
        $('#comments').appear( function() {
            console.log('appeared');
            var password_on = false;
            var website_on = false;
            var email_on = true;
            var canon_url = (document.querySelector('link[rel="canonical"]') != null) ? 
                                '?canon_url=' + encodeURIComponent(document.querySelector('link[rel="canonical"]').getAttribute('href')) 
                                : ''; 
            var load_url = 'http://www.mydomain.com/hashover.php' + canon_url;
            document.write('<script src="http://www.mydomain.com/hashover.php' + canon_url + '"><\/script>'); // redirects so the page loads only the editor (!)
            $('#comments').html('<script src="http://www.mydomain.com/hashover.php' + canon_url + '"><\/script>'); // redirects so the page loads only the editor (!)

            $('body').append('<script type="text/javascript" src="http://www.mydomain.com/hashover.php' + canon_url + '"><\/script>'); // redirects
            $.getScript('http://www.mydomain.com/hashover.php' + canon_url, 
                function(data){
                    $('#comments').html(data); // redirects
                }
            ); 
            $.ajax({
              url: load_url, // redirects 
            }).done(function ( data ) {
                console.log(data);
                $("#comments").html(data);
            });
        });
    }
});

No chance to get the load on appear and prevent the redirect. What is the reason for this behaviour?

First an issue, then also a suggestion.

I recently changed my postfix to be at a subdomain mail.tapebrain.com so what would I need to change here?

$this->setting['domain'] = $_SERVER['HTTP_HOST'];

As I'm not getting any notifications, I assume me changing to subdomain is the issue?

Also, while we're at topic of notifications...

Before posting, perhaps a checkbox to receive/not receive them?
A subscribtion option? So someone can subscribe to the comments and get updates

Edit: Updated to reflect the current state of HashOver's support for different data storage formats. Serialized PHP is no longer being considered.

It seems advantageous to move away from XML as HashOver's default data storage format. The following is a list of considerable replacements. Any formats that require additional libraries or installation and/or configuration of server-side software (ie. MySQL) to employ or that are only available in PHP versions higher than 5.3, aren't being considered.

I won't use a database for the sake of using a database, most of the data formats below have more benefits within the context of HashOver than a database provides. The only benefit databases provide is a secure way to store password hash salts, but it is recommended that the comment files have no public read, write, nor execute permissions, thus securing the files just as significantly.

I'm considering the following things: human-readability, compatibility, speed, character set support, and interoperability. I will only use the format that best satisfies these conditions.

JSON

JSON seems the most logical since HashOver's default mode is JavaScript. JSON is very human-readable, very compatible, seems to have the same or greater character set support, and would be the easiest format to move to from XML.

The good

• JSON is typed, in addition to string it supports integer, float and boolean, whereas everything in XML is treated as string type when parsed by PHP. This is inconvenient for a number of reasons, for example, adding a float value (1.66) from XML to an integer variable in PHP (5) returns a new integer with a value equal to the sum of the two (6), not a float (6.66), in other words it's a floored value. In XML it's also impossible to store an actual boolean value, and tags with the same name become arrays instead of overwriting each other.

• JSON is easy to load asynchronously for those who desire to use the comment files that way. Simply loading the JSON comments as-is would be a security risk and should be avoided, however, loading the JSON comments, decoding them, removing the sensitive data, and returning the re-encoded data would be secure and very simple, while doing the same with XML files requires more code.

• JSON is also slightly smaller than XML. The current overhead for each XML file is 204 bytes, JSON's overhead would be 153 bytes. 1,000,000 comments containing "Hello, World!" in XML would equal 217,000,000 bytes, in JSON 166,000,000 bytes, therefore...

  let xml = 217,000,000
  let json = 166,000,000
  
  xml ÷ 1,024² = 206.9 megabytes
  json ÷ 1,024² = 158.3 megabytes
  ((json − xml) / xml) × 100 = −23.5%
  

  That means JSON's overhead is 23.5% smaller than XML with XML taking up 48.6 megabytes more per million comments. That isn't very significant. Note that in a comment like this: comment #33 the XML overhead makes up for only 8.6% of the file, and in JSON only 6.4%.

The bad

• Although JSON can be stored with pretty print, thus increasing its readability, it doesn't support multi-line items. This means most comments will appear on a very long single line when viewing or editing them in a text editor, whereas XML comments are stored with one paragraph per line.

SQLite

SQLite is well supported by PHP, it's a very well known data storage format, and unlike MySQL and many other *SQLs, SQLite doesn't require configuration of server-side software. PHP creates a file with a .sqlite extension and writes the data to that file.

The good

• SQLite allows comments to be deleted securely by overwriting deleted content with zeros, making it harder to recover intentionally deleted comments.

  This isn't normally true of data formats where individual files are used, such as XML and JSON, unless the web server has an SSD and its filesystem is using TRIM, or if the deleted comments were to be shredded after being deleted.

• SQLite may provide benefits relating to file size, however, as stated above, the current overhead isn't much, a database reducing it significantly is not likely.

• SQLite may provide an increase in performance and querying speed, but not very significantly since all of the comment files are extremely small, modern filesystem overhead is negligible, and the code doesn't need to do any kind of query searches.

The bad

• SQLite is the least human-readable data format on this list. Every SQL-based database requires specific -- often proprietary -- software capable of reading SQLite database files in order to access the data. When the data is made available to the user in a human-readable and editable way, it's often in the form of a single line, and editable in only a very limited way.

• SQLite's secure delete feature has the negative side-effect of increasing the size of the database until the database can be "compacted".

• All databases and other single-file formats, including SQLite, can be easily corrupted and/or compromised. If the database gets corrupted, everything is corrupted, meaning every comment on every page would be corrupted. If the database gets compromised, every e-mail and password every user ever used would be compromised at once.

  This isn't true of data formats where individual files are used, such as XML and JSON, since only a single file can be corrupted and/or compromised at a time.

Support custom data format classes

Similar to how the Login class provides the means to load any compatible class providing a mechanism for managing a login -- for which the DefaultLogin class provides the default login mechanism. Theoretically, this is already the case, ParseXML, ParseJSON, and ParseSQL are classes that provide the XML, JSON, and *SQL data formats, respectively.

What is needed here is documentation about how to write a proper data format class for HashOver, and a template from which a developer may base their class.

The good

• Anyone could write and use additional data format classes so long as they return all the information HashOver expects. For example, an OAuth class could provide an OAuth login mechanism.

The bad

• It is inconvenient for a user to have to write their own class to use a specific data format, therefore a minimum number of data formats should be supported by default.

Others

If anyone has recommendations, please feel free to comment here or open specific issues. It is likely that all of the above data formats will be supported upon release, with an additional option in the settings for choosing between them, in such a case the question of data formats becomes:

"Which should be the default?"

I was doing some extra optimization and wanted to load hashover's stylesheet directly from wordpress instead of letting the comment system handle that.

It would be nice to have an option to say 'null' or similar in the settings to disable the stylesheet loading.

I temporarily removed the loading if code in javascript-mode.php on line 63 to achieve that result but would be simpler to have an argument we can pass.

In fact all instances of Object Inheritance in general are messy, nothing really wrong, just not nice looking, easy to work with, easy to understand, maybe not as efficient... definitely 2.0 stuff.

Just an idea...

Since we already have a message 'be the first to comment', having 'SHOWING 0 COMMENTS:' above it seems unnecessary.

Imo, it would look cleaner without it, what do you think?

In case you missed it, or maybe it's just me, hashover won't load, Chrome inspector throws the error for this:

var show_cmt = '';

that's for javascript-mode.php, php mode loads fine

Finally able to work with the new release. In any case everytime I post a test comment I get the following in my logs

PHP message: PHP Warning: Missing argument 3 for Cookies::set(), called in htdocs/hashover/scripts/writecomments.php on line 132 and defined in htdocs/hashover/scripts/cookies.php on line 46 PHP message: PHP Notice: Undefined index: status in htdocs/hashover/scripts/writecomments.php on line 171 PHP message: PHP Warning: Missing argument 3 for Cookies::set(), called in htdocs/hashover/scripts/writecomments.php on line 466 and defined in htdocs/hashover/scripts/cookies.php on line 46 PHP message: PHP Warning: Missing argument 3 for Cookies::set(), called in htdocs/hashover/scripts/writecomments.php on line 467 and defined in htdocs/hashover/scripts/cookies.php on line 46" while reading response header from upstream

Any ideas?

I'd say this is a very important change. BR tags looks awful and styling them with css is very hacky.

Each line should be enclosed in <p></p>

Am checking out writecomments.php and got kind of spooked :p

It's getting late and not sure if I messed something up but in any case the widget didn't load and here are the log errors

[error] 1059#0: *303800 FastCGI sent in stderr: "PHP message: PHP Notice: Undefined index: path in /hashover/scripts/setup.php on line 185 PHP message: PHP Notice: Undefined index: path in /hashover/scripts/setup.php on line 189 PHP message: PHP Warning: array_merge(): Argument #2 is not an array in /hashover/scripts/parsejson.php on line 44 PHP message: PHP Catchable fatal error: Argument 1 passed to DisplayComments::parse() must be of the type array, null given, called in /hashover/api/latest.php on line 95 and defined in /hashover/scripts/displaycomments.php on line 83" while reading response header from upstream

Failed to execute 'write' on 'Document': It isn't possible to write into a document from an asynchronously-loaded external script unless it is explicitly opened.

In Chrome inspector

I've been doing some research and while I visually love having only placeholders, not having labels is an accessibility problem.

e.g. https://longhandpixels.net/blog/2014/02/html5-placeholder-label-search-forms

Perhaps the best solution would be to add an option to display labels (for the inputs). So if someone doesn't want them they don't have to use css hacks to hide them.

Actually maybe best to have them on as default .

Consider the following:

1. XML parse time for 10 files: 0.0003 seconds.
2. HashOver execution time with 10 XML files: 0.0025 seconds.

Now let's say there's 1000 files:

HashOver's execution time would be 2.5 seconds, whereas the XML's parse time is only 0.3 seconds. That means 88% of the execution time is HashOver itself, considering HashOver is doing very little work to display the comments, and most of it is done in JavaScript on the client's web browser, this is unacceptable. It needs to be fixed before HashOver becomes like Disqus :-)

Memory is also high as well, with script memory peak of 0.51Mb and system memory peak of 0.75Mb for only 10 XML files. These numbers should be around 0.22Mb for 1000 files not 10.

Browser cookies set and used by HashOver are used without being sanitized first. There is some sanitation happening in the form of removing certain characters, however, code injection may be possible currently, though, I don't know to what degree.

Two possibilities:

1. Cookies not set by HashOver may simply allow characters like < and > to be used, thus breaking or otherwise messing with the page layout for the individual user.
2. Cookies not set by HashOver may allow an attacker to read and/or write to server-side files, like .htpasswd, or to execute BASH or PHP commands like mail() in order to send spam using a HashOver user's server.

This issue will be thoroughly investigated and fixed as necessary.

Been debugging something else on my site, turned back all error logging (not just crit) and saw a bunch of warnings concerning hashover... Here they are so let's see if some are my fault and which can be fixed in the app:

FastCGI sent in stderr: "PHP message: PHP Warning:  file_get_contents(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0 in /var/www/mysite/htdocs/hashover.php on line 117

I have fopen off as it's suggested pretty much everywhere, especially concerning Wordpress etc. security

PHP message: PHP Warning:  file_get_contents(http://www.stopforumspam.com/api?ip=109.60.93.217): failed to open stream: no suitable wrapper could be found in /var/www/mysite.com/htdocs/hashover.php on line 117
PHP message: PHP Strict Standards:  Only variables should be passed by reference in /var/www/mysite.com/htdocs/hashover/scripts/parse_comments.php on line 33
PHP message: PHP Strict Standards:  Only variables should be passed by reference in /var/www/mysite.com/htdocs/hashover/scripts/parse_comments.php on line 33
PHP message: PHP Strict Standards:  Only variables should be passed by reference in /var/www/mysite.com/htdocs/hashover/scripts/read_comments.php on line 67
PHP message: PHP Strict Standards:  Only variables should be passed by reference in /var/www/mysite.com/htdocs/hashover/scripts/parse_comments.php on line 33
PHP message: PHP Strict Standards:  Only variables should be passed by reference in /var/www/mysite.com/htdocs/hashover/scripts/read_comments.php on line 67
PHP message: PHP Strict Standards:  Only variables should be passed by reference in /var/www/mysite.com/htdocs/hashover/scripts/parse_comments.php on line 33
PHP message: PHP Strict Standards:  Only variables should be passed by reference in /var/www/mysite.com/htdocs/hashover/scripts/read_comments.php on line 67
PHP message: PHP Strict Standards:  Only variables should be passed by reference in /var/www/mysite.com/htdocs/hashover/scripts/parse_comments.php on line 33
PHP message: PHP Strict Standards:  Only variables should be passed by reference in /var/www/mysite.com/htdocs/hashover/scripts/read_comments.php on line 67
PHP message: PHP Strict Standards:  Only variables should be passed by reference in /var/www/mysite.com/htdocs/hashover/scripts/parse_co
2014/04/26 18:54:38 [error] 29530#0: *781 FastCGI sent in stderr: "PHP message: PHP Notice:  Undefined variable: js_title in /var/www/mysite.com/htdocs/hashover/scripts/javascript-mode.php on line 443" while reading upstream, client: 109.60.93.217, server: mysite.com, request: "GET /hashover.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "mysite.com", referrer: "http://mysite.com/thoughts/blabla/"

I'm not sure if these are connected and/or if the problem for some of them lies with my nginx config.

For reference, I'm using latest php 5.5, nginx 1.7

I couldn't figure out where to change this in code.

Currently, the div class is the same for the notice and for the first actual comments.

So if you for example add a background color for .hashover-header and some padding, it will appear above the notice and look ugly

PS. Where is the string to change the text?

I think that some installation instructions would surely make it easier for newcomers to provide feedback.

I would like to provide only two fields frontend: "nickname" and "e-mail".

However, the login button and the password field will not be shown that are necessary for the admin action to edit and delete comments.

How can I login now? ... A comment-manager-page would help here :)

Previously I used

<script type="text/javascript">
        var passwd_on="no";  // Disables "Password" field
</script>

and the password + login button wouldn't be visible. Now they're shown regardless.

What would be the equivalent with the new updates?

I've been testing this on my test page which doesn't have any other js interference.

As the title says, after making a new post the user stays at page top, even though the url has the anchor. Same goes for logging in.

Only on my end?

Was just doing some testing and found this:

• User making first post enters just his name
• Submits post but can't edit that first post
• Submits second post and can edit that one

When I try a different user, this time with a password, he can immediately edit his first post.

Excluding avatars.php and like.php all files should depend on and not be executable outside of hashover.php. Spamming and other malicious actions may be possible by sending input directly to files under hashover/scripts/.

Examples of existing problems

1. Files under hashover/scripts/ accessed directly from a browser throw PHP errors.
2. hashover/scripts/write_comments.php doesn't have spam checking, because that is implemented in hashover.php, sending input directly to hashover/scripts/write_comments.php may allow spam to be posted.

Just got a human troll that posted a dozen spam comments.

For this script we definitely need:

1. IP blocker
2. Moderate option

I guess this implementation would be easier with a database?

Perhaps a bit more detailed explanation is needed in the code comment.

I personally would like to know what is the difference between javascript and php in this setting?

The explanation on the installation page isn't very detailed.

I get an

Uncaught SyntaxError: Unexpected identifier

viewing in chrome's inspector. Blank page on page reload after submit. Here are the errors

Warning: preg_match() expects parameter 2 to be string, array given in /etc/hashover/scripts/displaycomments.php on line 152

Notice: Array to string conversion in /etc/hashover/scripts/encryption.php on line 100

Notice: Array to string conversion in /etc/hashover/scripts/encryption.php on line 101

Notice: Undefined index: Array in /etc/hashover/scripts/encryption.php on line 78

Warning: mcrypt_decrypt(): The IV parameter must be as long as the blocksize in /etc/hashover/scripts/encryption.php on line 110

Notice: Array to string conversion in /etc/hashover/scripts/encryption.php on line 100

Notice: Array to string conversion in /etc/hashover/scripts/encryption.php on line 101

Notice: Undefined index: Array in /etc/hashover/scripts/encryption.php on line 78

Warning: mcrypt_decrypt(): The IV parameter must be as long as the blocksize in /etc/hashover/scripts/encryption.php on line 110

XML working fine

PHP 5.6 is out. Will you have the chance to test for any issues or let us know if any of the listed changes could affect hashover?

http://php.net/manual/en/migration56.incompatible.php

Cheers

Code comments in the CSS are necessary documentation for users to customize the look and feel of HashOver. There are also many redundant declarations that make it more difficult to work with.

I'd like to implement Latest comments on my site.

My question is: what's the idea on how to use the provided API files?

Should I include latest.php somewhere in order to call a function? Or, if I concluded correctly based on the theme widget files... there's a way to call the widget that already utilizes latest.php?

Thanks

Let's say I post a comment using just a name, I get logged in by default.

I log out, then post a comment as anonymous and I automatically get logged in.

Is this intended ?

I wanted to make direct changes here but I never used github properly so until then:

in comments_parse.php, line 197 we should at least have a class for 'Top of thread' link so it can be further styled as needed, and float:right moved to the default css.

Correct me if there's a reason not to do this.

Cheers

Should this perhaps point to github?

Currently it points to website root/hashover.zip, which by default won't exist

Can't seem to find in the code where to fix this, but the idea is to not load the avatar when the $icons variable is set to no.

It doesn't display on the comments themselves but it appears in the reply/edit table when one clicks options.

We can hide it with css but it still loads the resource so not the best solution