Increase pagination index to start from 1 instead of 0.
So in URL instead of ?page=0 it should be ?page=1 for first page and then ?page=2 so on..
This question is documented in Drupal core issue #1818040. It looks like the patch from comment #15 needs to be re-rolled for the latest minor release. If you are working with a limited code line and have control over your content, that might be enough. However, in the long term it looks like a fix needs to be found for the fact that this implementation is going to break URLs on existing sites and potentially interfere with other contributed modules.
Side note: I would like to go ahead and call to your attention an article written by Edsger W. Dijkstra's titled "Why numbering should start at zero". When you say "such and such event is happening in three days" you do not mean the day after tomorrow but rather the day after the day after tomorrow. Your count does not begin with today but rather tomorrow, as today is when you begin counting (today = 0).
TL;DR: In the case of your book, the first page you encounter is the beginning, and you cannot begin counting before you have begun reading.
Related
I'm coming from a SCORM end and trying to figure out two related issues with how to do update and find the most recent data (ie, looking for best practices).
In SCORM I'd have a set of activities that would all store their answers and scores (easily understandable from the docs etc). The "how" I'm after is specifically related to resuming the set of activities multiple times, and hitting "reset" and submitting a different answer to a single activity after a statement has been sent in.
From what I read with xAPI it states that statements are immutable - so how would I go about this.
My first thought was that I'd make the statement id generated from the activity id and void the old answer when it changes - but that sounds wrong (not least because it reads like you can't re-use the id even with voiding).
So it looks like the Statement id needs to be unique, which would mean that multiple identical Objects would be found - so would I have to look through every attempt and check for the latest one?
I'm currently looking at using xAPIWrapper in the middle.
Moving from SCORM to xAPI requires a change of mindset. SCORM deals with statuses which get updated; xAPI logs events like a journal.
You can think of it like Facebook. You post a photo of your new cat; a month later you post a photo of your cat 1 month older. There's no need to go back and delete the old post. If you want the latest photo of your cat you just go and get the most recent photo tagged "Ryochet's cat". You can also look at older photos to see how your cat developed. xAPI is like that activity stream on Facebook.
So, if somebody scores 10 points on their first attempt, then 20 points on their second attempt, you'd simply send a second set of statements about the 2nd attempt. There's no need to get rid of the statements about the old attempt, that happened and is useful data to see how the learner developed.
I'm using fullcalendar 1.6.4 in conjunction with a Drupal 7 site; all is well except that I'm getting the wrong number of weeks for some months with weekMode set to "variable" or "liquid". For September 2013, I get four rows of weeks, which means that I lose the last two days of the month. Most other months appear correctly, although December 2012 is shown with 5 weeks (losing the 30th and 31st), and January, February, and October 2013 are all shown with 6 weeks (one more than is needed).
I've been doing some quick hacking around with the render() code where the starting and ending dates seem to be worked out, but haven't come up with anything clearly better. So: are other people seeing this / is it a known issue / have I screwed up something with my installation? Thanks!
I think there's a bug here: in fullcalendar.js's MonthView.render(), it looks like the AddDays computation of visEnd (l. 1984) is getting messed up by firstDay getting string-concatenated into the value instead of added. visStart may be getting similarly affected, since it does pretty much the same thing. In any case, I stuck the line firstDay = parseInt(firstDay, 0) after the var FirstDay... statement, and things are working properly for me. This may not be the preferred way of handling the matter, but I think something like this is going on. Opinions from other eyes?
This is not a Full Calendar bug, but instead a bug in the Drupal implementation of Full Calendar. Drupal allows users to override the "start of the week" option (values of 0 to 6). Drupal is incorrectly storing this value as a string instead of a number.
See Drupal issue I opened.
I’m using the heartbeat module on my site to make an activity-stream and recently I discovered that it doesn’t display all the new comments.
I’ve displayed group messaging ‘cause I only want to display #username commented on #node_title and nothing more. But for some reason, when there is several comments submitted within a short range of time it either only displays one of the comments or nothing or it makes an entry in the activity-stream which is just blank.
Before I was using the built-in comment-template in Heartbeat but now I’ve tried to create my own instead. It works when I post a comment but when testing it and makes two comments within e.g. 30 seconds it still makes the error.
Are there any known problems with this issue or am I missing something?? I haven’t detected the problem with adding new nodes, which also can occur within a short period of time on my time.
Thanks
Sincere
- Mestika
If you are having display failures in Views, there is a patch someone worked out in February 2012 for Views 6.x-3.x - you might want to try that. It fixes the display for a bunch of fields. See http://drupal.org/node/1295570
I have a potential maths / formula / algorithm question which I would like help on.
I've written a questionnaire application in ASP.Net that takes people through a series of pages. I've introduced conditional processing, or branching, so that some pages can be skipped dependent on an answer, e.g. if you're over a certain age, you will skip the page that has Teen Music Choice and go straight to the Golden Oldies page.
I wish to display how far along the questionnaire someone is (as a percentage). Let's say I have 10 pages to go through and my first answer takes me straight to page 9. Technically, I'm now 90% of the way through the questionnaire, but the user can think of themselves as being on page 2 of 3: the start page (with the branching question), page 9, then the end page (page 10).
How can I show that I'm on 66% and not 90% when I'm on page 9 of 10?
For further information, each Page can have a number of questions on that can have one or more conditions on them that will send the user to another page. By default, the next page will be the next one in the collection, but that can be over-ridden (e.g. entire sets of pages can be skipped).
Any thoughts? :-s
Simple answer is you can't. From what you have said you won't know until you have reached the end how many pages the user is going to see so you can't actually display an accurate result.
What you could do to get a better result as in your example is to assume they are going through all the remaining pages. In this case you would on any page have:
Number of pages gone through so far including current (visited_pages)
Number of the current page (page_position)
Total number of pages (total_pages)
The maximum number of pages is now:
max_pages = total_pages - page_position + visited_pages
You can think of total_pages-page_position as being the number of pages left to visit which makes the max_pages quite intuitive.
So in the 10 page example you gave visited_pages = 2 (page 1 and page 9), page_position = 9 and total_pages = 10.
so max_pages = 10-9+2 = 3.
then to work out the distance through you just do
progress = visited_pages/max_pages*100
One thing to note is that if you were to go to pages 1,2,3,4,9,10 then your progress would be 10%,20%,30%,40%,83%,100% so you would still get a strange jump that may confuse people. This is pretty much inevitable though.
Logically unless the user's question graph is predetermined, you can not predetermine their percentage complete.
That being said.
What you can do is build a full graph of the users expected path based on what information you know: what questions they have completed, and what questions they have to take, and simply calculate a percentage.
This will probably involve a data structure such as a linked list to calculate where they have been, and what the user has left to complete, this implementation is up to you.
The major caveat here is you have to accept that if the users question graph changes, so will their percent completed. Theoretically they could display 90% and then it changes and they will display 50%.
I am working on a project using Drupal 6 (6.11 at the moment, haven't yet upgraded to 6.12) and part of the core functionality is the ability to vote on nodes. I'm having some rather weird behaviour that has taken me an age to track down and now I have, I still can't fix it.
This is what I've managed to figure out so far:
The template file sites/default/modules/vote_up_down/theme/vote_up_down_points.tpl.php automatically calls the function template_preprocess_vote_up_down_points() from vote_up_down.module.
vote_up_down.module then queries the database using the values stored in the $variables array that is passed to it
On only one of the 3 occasions this is called on a typical node (in this case forum posts) $variables doesn't have a value for $variables['cid'].
That one occasion is when it reads the score so as to display it below the post itself. And, instead of locating the current post's score, it locates the first-ever-voted-on post's score. (This is because instead of returning the score of one post, it returns the score of all posts and then uses the first one from the list).
I am assuming that $variables is a system-wide constant (looking at the content of it using print_r seems to confirm that) and so perhaps this is a core bug as it should always be the same. I checked the contents of $variables and the only 4 parts of around 50 that are different in the one that doesn't work are: cid - blank, tag - blank (although this is discovered by the function and correctly substituted as 'vote'), zebra - even & id - 2. I imagine the last 2 are not really important for this, so the key must be in why $variables['cid'] is not being passed through.
So, my questions are:
Has anyone had this problem before and how did you fix it?
If not, do you have any tips as to how I can figure out why this is not working correctly?
I can't tell you the answer, but you'll probably have better luck posting this in the module's issue queue, since then the maintainer and others using it will see it.
I can't believe I didn't try this before, but I just upgraded to the latest development snapshot of vote_up_down and the problem went away. A 2 minute fix in the end vs about 6 hours of trying to tie the problem down.
Lesson learnt!