Like Posts

[Joker™]

Chrome's javascript console didnt report an error. I tried using english for the like link and traditional chinese for the unlike link and that worked both ways. Just doesn't work if the like link is in traditional chinese.

cheers

Can you provide me the chinese translation file you are using.

Here it is. Thanks a bunch.

Thanks a lot for the file. Right now I'm implementing changes to show total likes of a user in posts. I'll be able to complete it in a day or two. After that I'll my best to push the fix for your issue.

[Joker™]

I've personally never liked how SMF refreshes pages while doing maintenance task in admin panel. A glimpse of admin maintenance for Like Posts mod .

[Arantor]

So you have a ton of JavaScript just for the benefit of pinging the server regularly to push through updates?

[Joker™]

So you have a ton of JavaScript just for the benefit of pinging the server regularly to push through updates?

Lol who said anything about pushing updates to server? I think I haven't even described the functionality completely yet .

That's just a progress bar to show how much server maintenance task for 'Like Posts Count' has been completed. SMF does that by refreshing page, sending params in url(or in outer space), perform calculations on it and shows it after page refresh. I did it with Javascript. Does this make server die?

[Arantor]

I think you grossly misunderstand the point of doing it the way SMF does it.

Servers are limited by how much can run in a single page load. That's why SMF pushes through several page loads, to make sure it never falls foul of that time limit per page load. If there's a serious maintenance job that would take more than about 15 seconds to run, it should definitely be split across page loads.

Having a single page that makes requests to the server to do it piecemeal is fine, but just running it in a single page load is going to be a serious problem whatever happens. I get the impression you're not doing it piecemeal.

[Joker™]

I think you grossly misunderstand the point of doing it the way SMF does it.

Servers are limited by how much can run in a single page load. That's why SMF pushes through several page loads, to make sure it never falls foul of that time limit per page load. If there's a serious maintenance job that would take more than about 15 seconds to run, it should definitely be split across page loads.

Having a single page that makes requests to the server to do it piecemeal is fine, but just running it in a single page load is going to be a serious problem whatever happens. I get the impression you're not doing it piecemeal.

Well I'm working very closely with server team, implementing API's on various types of servers and DB's like
- RoR
- Tomcat/java
- MySQL/PHP

and personally, if
- the task is broken into pieces
- adequate execution time is given to task
- and next call is done with some gap

Server is happy as us.

I've personally designed and created a complete sync functionality which sync's data from one device to another using server(tomcat) as medium, and TBH it makes a very extensive usage of server. Even in that case server held up nice. Not to forget workforce of 1000 employees were using the app and server was a company wide server. Above all that the app is live from past 6 months, and we haven't received a single complaint either from users or server team.

Another app registers every single move a user makes on device and sends it to server, just think of data volume for that.

Basically it all goes to how efficient your thread are.

Best examples are og gmail and facebook which makes usage of long poling to check for notification/chats.

You can view the code pushed for the functionality over here. Please point out any errors you see .

- Jokerzzz

[Arantor]

No, it really doesn't go to 'how efficient your thread are', that's nonsense. Maintenance tasks, by definition, are heavyweight and often longer running processes so they must be broken up. And you can't just multithread that stuff, either. An understanding of what will be blocking behaviour vs not blocking is quite important in this sort of situation.

Also, what the hell has long polling got to do with it? You cannot meaningfully generate long polling on a PHP environment, you will quickly max out Apache/PHP's connection limit. It's a bit different on nginx and PHP-FPM where you can let nginx handle the connection but PHP is just not designed to work with sitting idle for long periods of time.


I see your code is breaking the task up. I see also that it's using $_REQUEST['endLimit'] without any sanitisation (and you're only protected because SMF itself will block an injection)

It's also using json_encode which is a PHP 5.2+ only function (there are a surprising number of people still not using 5.2+ and of those that are, json_encode is not necessarily enabled). as opposed to, say something like:

Code Select Expand

echo '{totalWork:', (int) $startLimit, ', endLimit:', (int) $endLimit, '}';

I also have no idea why you're duplicating the admin panel code, template_lp_admin_general_settings doesn't do anything that template_show_settings wouldn't except show the tabs but if properly set up, the generic menu template should be doing that for you in the first place.

Interesting also that you nuke the entire count of likes before beginning, you could save a lot of queries by not doing that, instead taking the query you already have, combine that with a query for getting the number of likes a user already has and comparing the two. If there are differences, push those to updates, if new rows are needed, do them all at once in a single insert statement, and if the new number is zero you can clear the row while you're at it (single DELETE query)

Right now with your default of 100 per page, you're guaranteeing to run 1 query for the first run, followed by 101 queries every single run through up until the last one. For most forums, the counts aren't going to significantly change for a significant number of members every time, and you might as well do a little more work to try to avoid unnecessary queries - which is more efficient in your thread.

[Joker™]

No, it really doesn't go to 'how efficient your thread are', that's nonsense.

Please keep it social. If once hasn't done anything persoanlly, it just doesn't mean it can't be done.

Maintenance tasks, by definition, are heavyweight and often longer running processes so they must be broken up. And you can't just multithread that stuff, either. An understanding of what will be blocking behaviour vs not blocking is quite important in this sort of situation.

Doesn't this depend on what sort of maintenance you are doing? By what you are saying it sounds like
Recounting total posts === Emptying logs tables

Also, what the hell has long polling got to do with it? You cannot meaningfully generate long polling on a PHP environment, you will quickly max out Apache/PHP's connection limit. It's a bit different on nginx and PHP-FPM where you can let nginx handle the connection but PHP is just not designed to work with sitting idle for long periods of time.

Really?? Well then I read a lot of articles on web and there is a nice topic on stackoverflow also. I think every one must be wrong.

I see your code is breaking the task up. I see also that it's using $_REQUEST['endLimit'] without any sanitisation (and you're only protected because SMF itself will block an injection)

Yeah, I know I've to palce a lot of validations yet.

It's also using json_encode which is a PHP 5.2+ only function (there are a surprising number of people still not using 5.2+ and of those that are, json_encode is not necessarily enabled). as opposed to, say something like:

Code Select Expand

echo '{totalWork:', (int) $startLimit, ', endLimit:', (int) $endLimit, '}';

Well, this has been in use since the first release of the mod, as the mod has various other sections which get data in json format.

I also have no idea why you're duplicating the admin panel code, template_lp_admin_general_settings doesn't do anything that template_show_settings wouldn't except show the tabs but if properly set up, the generic menu template should be doing that for you in the first place.

Lol, I love to add things in templates anything, so its better to keep them separate.

Interesting also that you nuke the entire count of likes before beginning, you could save a lot of queries by not doing that, instead taking the query you already have, combine that with a query for getting the number of likes a user already has and comparing the two. If there are differences, push those to updates, if new rows are needed, do them all at once in a single insert statement, and if the new number is zero you can clear the row while you're at it (single DELETE query)

Ummm, right now we are calculating the number of likes of a user only. Not sure about the query comparison you said above. Also are you saying, get total likes of user(with current query set) and match it with total likes of user in table? Well if that's the case then it sounds more resource consuming process to me.

Right now with your default of 100 per page, you're guaranteeing to run 1 query for the first run, followed by 101 queries every single run through up until the last one. For most forums, the counts aren't going to significantly change for a significant number of members every time, and you might as well do a little more work to try to avoid unnecessary queries - which is more efficient in your thread.

Not sure why 101 queries afterwards, as total query count is calculated once and won't be calculated again.

[Arantor]

Please keep it social. If once hasn't done anything persoanlly, it just doesn't mean it can't be done.

How is that relevant? I never brought in my experience or made this personal. If you like I can indeed do that. Just because I may not personally have done something doesn't mean I can't assess how someone else has done it.

My point is that it doesn't matter 'how efficient' a thread is, unless you take into consideration everything around it.

Doesn't this depend on what sort of maintenance you are doing? By what you are saying it sounds like
Recounting total posts === Emptying logs tables

Depending on the operation in question it might actually be that bad. SQLite for example would require a major file rewrite to achieve that (because one file contains the entire database)

But I'm sure you already knew that, right?

Really?? Well then I read a lot of articles on web and there is a nice topic on stackoverflow also. I think every one must be wrong.

Long polling is doable in PHP but that doesn't make it a good idea. Long polling by definition means holding the connection open until the server pushes a response. The way Apache/PHP works is that the connection will be open, with the PHP instance created, which means 8-10MB of memory consumed, while the process remains in idle. Then every new long poll works in the same way, holding the connection open, which means one of two things will happen: either the MaxChilds directive will exhaust or the server will run out of memory holding all the connections open.

Switching to PHP-FPM alleviates this to a point by having a pool of PHP instances, but then you're still needing to deal with the connections themselves. nginx will let you handle that but it gets ugly.

Oh, and I guess you already also are a Zend Certified Engineer and thus know PHP inside out?

Well, this has been in use since the first release of the mod, as the mod has various other sections which get data in json format.

And no complaints about a lack of json_encode? Surprising. Heck, even WordPress has to push a patch out for a lack of json_encode in servers.

Ummm, right now we are calculating the number of likes of a user only. Not sure about the query comparison you said above. Also are you saying, get total likes of user(with current query set) and match it with total likes of user in table? Well if that's the case then it sounds more resource consuming process to me.

Yes, that's what I'm saying. Get the total likes of the users, match against the current users' counts. It's actually cheaper to do that than to mindlessly update everything every time.

You see, by destroying the table, you force everything to be rebuilt/updated. As opposed to leaving the table alone and just updating the rows that are required.

In your current code - the first run will occur as follows:
Query 1 - truncate the table
Query 2 - get the count for this set of users
Query 3 to query 102 - update the counts for each of those users

The second run will be:
Query 1: get the counts for this set of users
Query 2 to 101 - update the counts for each of those users

(When doing anything this like, assume worst case scenario, which is the full set of 100 rows being returned from your getting query)

In fact... now that I look at it, you're actually rewriting rows over and over, as opposed to the quicker route of getting a set of users (step through the members table 100 members at a time), then getting the counts for those users both in terms of what's in the messages table (since you can make use of the owner index on the messages table) and what's in the like_count table, and doing the comparison - and here's the thing... in most cases the number shouldn't be changing on a regular basis between maintenance, so there's no need to keep updating rows - set the row once for per user for a maintenance run.

In other words, do it the same way the recount member posts stuff works because that does work (and that's processing much the same load)

[Joker™]

Depending on the operation in question it might actually be that bad. SQLite for example would require a major file rewrite to achieve that (because one file contains the entire database)

But I'm sure you already knew that, right?

Yup.

And no complaints about a lack of json_encode? Surprising. Heck, even WordPress has to push a patch out for a lack of json_encode in servers.

Hmmm, point taken, will try to implement a fallback.

Yes, that's what I'm saying. Get the total likes of the users, match against the current users' counts. It's actually cheaper to do that than to mindlessly update everything every time.

You see, by destroying the table, you force everything to be rebuilt/updated. As opposed to leaving the table alone and just updating the rows that are required.

In your current code - the first run will occur as follows:
Query 1 - truncate the table
Query 2 - get the count for this set of users
Query 3 to query 102 - update the counts for each of those users

The second run will be:
Query 1: get the counts for this set of users
Query 2 to 101 - update the counts for each of those users

(When doing anything this like, assume worst case scenario, which is the full set of 100 rows being returned from your getting query)

In fact... now that I look at it, you're actually rewriting rows over and over, as opposed to the quicker route of getting a set of users (step through the members table 100 members at a time), then getting the counts for those users both in terms of what's in the messages table (since you can make use of the owner index on the messages table) and what's in the like_count table, and doing the comparison - and here's the thing... in most cases the number shouldn't be changing on a regular basis between maintenance, so there's no need to keep updating rows - set the row once for per user for a maintenance run.

In other words, do it the same way the recount member posts stuff works because that does work (and that's processing much the same load)

Point taken.

[miguel]

Nice and excellent mod.
But I have a problem: I tried to translate it into spanish, thinking on give you the translated strings, but for an unknown reason, when I like in posts index, it shows only (), and for one second the button turns into "Unlike", but then it turns again into "Like".
Maybe it is a problem with spanish accents?

same problem in 1.1.1

[Joker™]

Nice and excellent mod.
But I have a problem: I tried to translate it into spanish, thinking on give you the translated strings, but for an unknown reason, when I like in posts index, it shows only (), and for one second the button turns into "Unlike", but then it turns again into "Like".
Maybe it is a problem with spanish accents?

same problem in 1.1.1

Thanks for the info. Will take care of this .

[Joker™]

Nice and excellent mod.
But I have a problem: I tried to translate it into spanish, thinking on give you the translated strings, but for an unknown reason, when I like in posts index, it shows only (), and for one second the button turns into "Unlike", but then it turns again into "Like".
Maybe it is a problem with spanish accents?

same problem in 1.1.1

Try the new version 1.2 .

[barnaby jonez]

Did you ever add the option to disable showing Liking on the board index, Joker?

[Joker™]

Did you ever add the option to disable showing Liking on the board index, Joker?

Yup, it already there .

[miguel]

Nice and excellent mod.
But I have a problem: I tried to translate it into spanish, thinking on give you the translated strings, but for an unknown reason, when I like in posts index, it shows only (), and for one second the button turns into "Unlike", but then it turns again into "Like".
Maybe it is a problem with spanish accents?

same problem in 1.1.1

Try the new version 1.2 .

Perfect 

[miguel]

No
there is a problem

The text in spanish is ok bat if I like a post and go to the other site of forum the post liked is no liked

I see the date base and the like_count id:member is wrong

[miguel]

The problem is  like button on board index
The liked in message is ok

[Joker™]

The problem is  like button on board index
The liked in message is ok

What is the exact issue with liking on message index? Also PM me the site link with a test account.

[SomaCruz]

When I give "Like" button nothing happens, sometimes only... What can it be?

Sorry for my bad english

I use 1.2 version and 2.0.5 smf