A few months ago I used Rowan Simms' 595 Library and associated DIY shield to build a 3-pin LCD. I had it all working fine.
Six months later, I plug it all back in and the LCD is only printing the first character of each test string. I'm using exactly the same code, the same pins on the arduino, and the same cables, but it just won't work right.
Does anyone have any idea what could cause this kind of error?
No, and without full information we probably never will. 
I'm not sure what other information to provide. I thought Rowan Simm's work was famous enough here, but if not then here's the link:
http://rowansimms.com/article.php/lcd-hookup-in-seconds
The wiring and code I use is identical. First time I built it, it worked fine. Now I've reconnected everything after letting it sit in a drawer for a few months, and the LCD is only printing the first character (if you code lcd.print("Testing"); then the screen displays "T", nothing else).
It's such a bizarre error that I wondered if anyone had experienced something similar.
PROBLEM SOLVED
The "only 1 character per line" problem arose with the latest Arduino IDE's, 1.6.6 and 1.6.7! It turns out that the LiquidCrystal_I2C libraries were written incorrectly, and returned a "0" when they wrote a character to the display using the low-level write() command. They are supposed to return a "1" when the character is sent, and a "0" when the operation fails. This minor bug did not cause any problem before, and went completely unnoticed, because the print() function used by the compiler/IDE (which calls to write()) did not care what the return value was. But suddenly, with IDE v1.6.6 on up, it seems to care! It sees the returning 0 and it stops printing!!
The solution is to FIX THE BAD CODE in the LiquidCrystal_I2C Library. This has been done for some versions of the library, but not for some others. And there seem to be all-too-many versions kicking around! THIS VERSION, from Marco Schwartz, was fixed last month:
I recommend that you DELETE your old LiquidCrystal_I2C library (this must be done by hand in your O/S; there is no way to delete Libraries in the IDE) and replace it with this one (install the ZIP file using the IDE in the usual way). According to the latest Library notes, the incorrect Print.write() function was fixed last month in it.
Then, recompile your code with the updated library and download it. Presto, everything works again.
I had this very problem, and it took me a whole day to figure out how to get things working again!
Grrrmachine:
I'm not sure what other information to provide. I thought Rowan Simm's work was famous enough here,
Never heard of him before now. 
If he contributes, I don't think he has in recent times. Or not on this forum.
The preferred library is fmalpartida.
Huh?!? "Preferred" by whom? I just read the thread where it was proposed that malpardita NewLiquidCrystal Library replace the LiquidCrystal Library. This proposal was rejected, and there were some pretty convincing arguments advanced (to me, anyway...) that this multi-headed library was a bad choice for a replacement! It also breaks as lot of the existing code, so far as I can tell, by using a different command set. And it is VERY hard to follow, IMO. Still, if it works for you, fine.
sblock, thanks for the extremely helpful comment. So it seems the problem also affects the LiquidCrystal595 library, since I'm not using the LiquidCrystal_I2C as far as I'm aware 
I'll send an email to the creator and see if there's any development on this.
I just read the thread where it was proposed that malpardita NewLiquidCrystal Library replace the LiquidCrystal Library. This proposal was rejected, and there were some pretty convincing arguments advanced (to me, anyway...) that this multi-headed library was a bad choice for a replacement!
How about giving us a link to this thread, I'd like to read it.
Don
Merry Christmas, all!
I am happy to oblige. Here is the link to the thread on GitHub about why some knowledgeable folks don't (yet) want to replace LiquidCrystal with NewLiquidCrystal:
Anyway, I am perfectly happy with the Marco Schwartz edition of the LiquidCrystal_I2C Library and am sticking with it, at least for now. I am especially grateful that it got patched so quickly when the bug was discovered, which obviously means that folks are actively "caring" for it. Great community!
Well Bill makes a convincing argument in that thread and I tend to agree with his assessment.
To get back to your earlier question (Huh?!? "Preferred" by whom?) . . .
The 'whom' refers to those of us who have been answering questions about how to get I2C adapters to work with LCD displays for the last year or so since they have become so inexpensive.
The problems is that there are no standards for how the IC on the adapter is connected to the LCD pins. Since the library must deal with those connections each implementation requires a specific library.
It seems that all of the manufacturers that do indeed bother to supply a library to drive their particular implementation seem to use the same name for their library. As a result some neophytes think that the libraries are interchangeable and try to use the wrong library with their particular adapter.
FMs library, by means of its constructor, is able to adapt to any of those configurations. When used in conjunction with the I2C guesser written by Bill (the same Bill as in the thread) which figures out the constructor argument, any of the currently available I2C adapters seem to work with the library.
I don't particularly care for the necessity to replace the built in LiquidCrystal library in order to use FMs, but for now that seems to be the best choice.
Don
So in short, the built-in library is useless and must be replaced by something, fmalpartida is a good choice but itself may cause some problems in certain circumstances; we clearly need (as a patch) the built-in library to be replaced with one that is halfway between and has the desired basic functionality including that to use with I2C adapters.
I certainly appreciate your perspective, and insight,on this. I can tell you from my own personal (bad!) experience that it's very frustrating to those of use who are still learning our way around the Arduino to be confronted with so many libraries that all have the same -- or very similar-- names, and which all claim to do the same thing, but, in fact, don't! It's even more frustrating when the IDE changes and "breaks" the code in its OWN ("approved/installed") libraries, and also when those libraries are so imperfectly managed -- for example, there's no Library DELETE command, and no track of inter-library dependencies.
I tried, at one point, to install the "fmalpartida" NewLiquid Crystal library. The documentation that it came bundled with could only be understood by an expert, and many of the online instructions found at the Bitbucket website were written in -- how do I phrase this? -- rather awkward/cryptic English (but that sure beat NO instructions...). Still, I promptly ran into a number of issues and conflicts, probably because I needed to delete some things first (and they didn't say which ones). Then, the NewLC library #include'd about 20 headers at the top of my code. I suppose I should have deleted most of those, but there was no guidance. The example code used lcd.begin() instead of lcd.init(), and a different syntax, with different numbers of arguments, to set up the lcd object from my earlier LC_I2C code. It was certainly not a straightforward, plug-and-play change from the LC library.
I had this unhappy experience because the new IDEs (1.6.6 and 1.6.7) "broke" all the old LC and LC_I2C Library code, in the sense that these compiled without error but failed to print properly. So all my working code stopped working, and I spent the better part of a day trying to figure out WHY! I realize that this was the fault of the older Library, and not really the IDE and its C compiler, in the sense that the original versions of the library did not properly respect the correct syntax/use of the C "write()" function. That's a shameful tyro error, by the way, that I would not have expected from a seasoned programmer. You'd think this sort of thing would get caught, sigh.
I really think there should be some Arduino "rules" about Library names and dependencies, and much better Library control/management. Otherwise, this Wild West approach is going to see many repetitions of the same problems. As you wrote, novices are having exactly the same issues, over and over again, in hooking up displays. It really should not be that hard, and I think the writers of Libraries are NOT doing an especially job of making it much easier. We would all benefit if they would to take a step back from their elegant code and think about some elegant documentation. Just saying...
Paul__B:
So in short, the built-in library is useless and must be replaced by something, fmalpartida is a good choice but itself may cause some problems in certain circumstances; we clearly need (as a patch) the built-in library to be replaced with one that is halfway between and has the desired basic functionality including that to use with I2C adapters.
Hear, hear!!!
Paul__B:
Never heard of him before now.If he contributes, I don't think he has in recent times. Or not on this forum.
The preferred library is fmalpartida.
This library works well for me, and doesn't have the aforementioned problem with the 'write()' function - it returns 1 as it should, with later versions of the IDE:-
#if (ARDUINO < 100)
void LCD::write(uint8_t value)
{
send(value, DATA);
}
#else
size_t LCD::write(uint8_t value)
{
send(value, DATA);
return 1; // assume OK
}
#endif
And I've never heard of Rowan Simms either.
And I've never heard of Rowan Simms either.
What about Marco Schwartz (Reply #8) ?
Don
floresta:
What about Marco Schwartz (Reply #8) ?
Don
Who's he?
As mentioned, I've had no problems with the fmalpartida library.
Edit: But I should add that I'm not saying it should replace the current "LiquidCrystal" library. It is a bit messy for newcomers, since it contains multiple libraries and doesn't suit the IDE's method of including a library. Clicking on >Sketch >Include library "NewliquidCrystal" does add a bunch of libraries to the sketch. I just type in the one that I'm using - "#include <LiquidCrystal_I2C.h>"
Just to keep this on track; can anyone confirm if any of the libraries mentioned in this thread support the use of a shift register?
Grrrmachine:
Just to keep this on track; can anyone confirm if any of the libraries mentioned in this thread support the use of a shift register?
The fmalpartida library has shift register support.
And that is exactly the point. It has everything!
Paul__B:
And that is exactly the point. It has everything!
It would be better to see it split up into individual libraries.
I notice that everyone is changing their minds pretty quickly in this thread. 
Personally, I'll keep using the fmalpartida library, for now at least. It's working fine, I know what parts to include for my purposes, and can't be bothered messing around changing to yet another library.