Sure, I get that it's a conflict that shouldn't exist, and that User Revision looks like the culprit. I just want to be absolutely clear exactly where the conflict does and doesn't occur.
In your last message you implied that installing UR first, then TC, that there were no errors. Is that actually the case, that the site is usable without removing the access rule? That would be quite strange if so!
But if it is true, what happens if you install TC, then disable (but not uninstall) it. then install UR, then re-enable TC?
Sorry to be picky, but will really help pin down the problem.
You've clearly found the module conflict. I don't know anything about how Total Control works, I've never used it.
I'm not quite clear if the conflict is permanent, or just causes a problem with order of installation. If you install User Revision first, then Total Control, do you still get errors?
Is Total Control usable after deleting the access rule? If so, then the workround is simply to remove the access rule.
I suspect this is something to do with the anonymous user. The update to 7.x.2.1 was to add a blank revision record for user 0, because of something only Drush appears to do (I think it was calling user_load(0) instead of drupal_anonymous_user()). Total Control may be doing something else unconventional.
The clue here is ctools_context_create_user(), which must be being invoked by one of your modules. It appears from the code that it is failing to load a user object, but very hard to see why and what the conflict with user-revision might be.
Have you any idea which module is using ctools in this way? I'm no expert on all the magic things that ctools can do, but if we can work out what's invoking it, it could provide more clues as to what's happening.
@TheoRichel
This issue was raised against 7.x-2.0-beta3, the current version is 7.x-2.37. The fix here is already incorporated in 2.37, so the patch is not relevant. Are you running the latest version?
It sounds to me that another bug may have crept in that's resulting in the same error message. It would be best to open a new issue, and describe how to replicate the problem.
Weird!
I've never used that reset module (didn't know it existed), but seems straight-forward, simulating a total re-install.
Maybe there's been some kind of sequencing problem in the installation of your site, but very hard to work out what might have been going on. Anyway, if it's working now then effectively problem solved.
It looks strangely like the installation may not have created the initial revision record for user 1. If that's the case I don't know why, but you can check with a SQL command like before:
drush sql-query "SELECT * FROM user_revision WHERE uid = 1"
You should get a record back with info corresponding to the user-1 account. If there's nothing then there's no record.
Did the additional users that work OK already exist before installing user-revision, or did you create them after?
Hi, I have to say I'm equally puzzled. Clearly nobody else does have the user/1 problem or we would have heard about it.
Some thoughts:
I assume you are logged in as user 1?
Do you get 404 on edit, or on view as well?
Is it the same with other user IDs?
What user_revision permissions are set?
I've created a new release 7.x.2.1 that includes this fix and a couple of other previous commits. Have you installed that release directly rather than 2.0 + patch?
What version of PHP are you running?
What OS and database?
I can't think of anything else relevant.
The patch in #32 fails on install because of behaviour of serial key columns. This patch works!
This patch incorporates a fix to the install code, and a schema update for when updating the module.
@vibrasphere:
The SQL commands clearly added the missing record, which has enabled Drush to run (the insert and update commands wouldn't produce any output unless there was an error). I'm happy that addresses the issue, and fixes the regression of #1053398: Possible problem with drush → .
The fact that you're still getting page-not-found on user profiles would seem to be another problem, and a conflict with another module. Only by installing modules one by one into a test site, after installing user-revsion, would it be possible to find out which one.
@Jelle_S:
Yes, I'm aware that happens at install time, and there is another bit of code that needs fixing. However, AIUI the module was just disabled, which doesn't change the database, and then re-enabled, which doesn't call hook_install. (Enable/disable was remove in D8, which I think was unfortunate).
If enabling a module updates the recorded schema version without invoking the update hook, then I'd call that a bug.
OK, so it thinks it's done the update. Maybe that's a result of enabling the module after updating the .install file, I'm not sure what Drupal does in that situation.
I'd like to check if the missing record has actually been created. Please run:
drush sql-query "SELECT * FROM user_revision WHERE uid = 0"
You should get a record, with all empty or 0 values. In particular, uid & vid (the first two values) should both be 0.
If you get no result then the update hasn't worked for some reason, so please run the following to create the record:
drush sql-query "INSERT INTO user_revision (uid, log) VALUES (0, '')"
drush sql-query "UPDATE user_revision SET vid = 0 WHERE uid = 0"
Following this you can re-run the select query, which should return the record.
I'm about to go out, so I may not be able to follow up now until tomorrow. Hope you get some success!
I think that snippet was for a later Drush for D8, seems there's a different Drush version for every version of Drupal.
After poking around, here's some other commands that should do the same thing:
drush eval "drupal_get_installed_schema_version('user_version');"
or maybe:
drush eval "print drupal_get_installed_schema_version('user_version');"
(I'm not sure if Drush by default outputs the result of an evaluated function.)
Some examples use php-eval instead of eval, I don't know the significance of the difference.
Or if that fails, Drush can do a direct SQL query:
drush sql-query "SELECT schema_version FROM system WHERE name = 'user_revision'"
I just need to know what schema version the system thinks it has for user_revision.
I don't understand why it says "no pending updates", but because of that it hasn't performed the update to add the missing record.
According to a quick web search you should be able to check the current schema version of the module as below - it shouldn't need to be enabled to do it.
drush ev "var_dump(drupal_get_installed_schema_version('user_version'))"
It was 7002, after applying the update it should be 7003. If it's still 7002 then update.php should see that the update needs to be run. Clearing cache might help.
The attached patch will add an update to the .install file. After applying it, as admin run the update.php URL. This should run an update for the module which will add the missing record.
Hopefully Drush will then work!
Looking back through the source history, I think the damage was done over 3 years ago in #2424671: User revision does not install on PostgreSQL → , a patch that was RTBC and I then committed when I first started using user-revision, before deciding to create the v2 branch. The whole install logic with the database was a bit of a mess at that time.
Indeed interesting, and waay before I started working on this module. I'll have a look at the source history, somehow that patch must have got lost. At least it confirms my analysis.
I should be able to complete a patch tomorrow. Are you OK applying patch files?
I know about Drush, but I've never found a need for it, and it now appears to need Composer to install even on D7, which I don't use either!
If my hunch is right it would affect Drush, as well as some module you're using on your older install. Finding which module is best done by installing them one at a time until you find the one that breaks the site.
Re databases do you have access to PhpMyAdmin or similar? That allows you to dive into the database tables.
If not I can do a patch to user_revision.install, which will allow update.php to add the row to the table. It might take a day or two for me to sort that out.
Ah, that's some progress. I can't test the drush issue directly as I don't use it.
However I've noticed that user-revision doesn't create a row in its table for user 0. There's not really a need as it's a pseudo-user and can't be updated anyway. I think this means that user_load(0) will fail, but Drupal itself never does that (perhaps drush does). You can make it happen using the URL user/0. This gives me Drupal's page-not-found (though not a system 404 error).
I then manually added a row to the user_revision table with uid & vid equal to 0, other columns empty (or null defaults). URL user/0 now gives access-denied.
Perhaps this is the problem, is a module you're using calling user_load(0) and not recovering from the error?
Could you try manually adding a uid = vid = 0 row to the user_revision table? Try it on both your installations.
The only way I can see that user-revision affects opening a user record for editing is that it adds hooks into the entity controller for the user account (the hook is pretty trivial though). If the entity controller fails to load the user object then 404 would be the result. But why it's doing this in your installation and nowhere else is a mystery.
It may be a conflict with another module, or some specific configuration. Would it be possible to do another clean Drupal install, and then install user-revision as the first additional module?
urgh. Is there anything relevant in dblog (after disabling user-revision), or in the system error.log?
Could you also check the database? in the users table there should be additional columns vid & ip, with vid initialised to the same value as the uid. There should also be a user_revision table, with values initialised as copies of the users table entries.
Thanks
Could you try removing that entity reference field and see what happens? I'm scrabbling in the dark a bit, so anything's worth trying.
It's very hard to see what's going on here.
Leaving aside why anything would be invoking views in the first place, the function in views_handler_field_entity could only be invoked via a sub-class, but nothing in user_revision extends this class either directly or indirectly. It's only extended by node and comment.
You say you have a custom text field in your account settings (I also have several which don't cause a problem), but do you by any chance also have an entity-reference custom field? That's the only route I can think that the code reporting the error could be called. Even so it's somewhat bizarre.
It's weird that editing a user triggers an error in views!
Is this the first time user-revision has been installed on this site? I had a lot of problems when I first tried 7.x-1.x, and did extensive work on it, the results of which became 7.x-2.x.
Could you try the later version and report results?
Arguable.
Viewing revisions is not like viewing content, it's implicitly an administrative function in itself. Viewing the revision history of content other than your own is not something a normal user should be doing. So "view any revision" implies administration. Adding another permission just to manage access to the configuration page - with 2 options, 4 if diff is enabled - strikes me as overkill. I can see an argument for using "administer users" as the permission to protect that page though.
Also, would an "administer" permission override view-any, revert-any, and delete-any? It starts to get messy.
The fix in patch #5, which expands the permission descriptions, was rolled into the 7.x-2.x release anyway, which I recommend using.
Just discovered a bug that can cause a fatal PHP error, especially when creating a content type. Updated patch attached.
TCPDF version could well be the problem. I have version 6.3.5, and that's at least 2 years old.
This is extremely puzzling. The error says that the method getCellHeight() doesn't exist, but the call is $this->getCellHeight(), i.e. to a method in the current class - or in this case a parent class. The calling code can only execute because the class has been instantiated, so how can the method not exist?
PdfTemplate's inheritance is not completely straight-forward though. It has a cascade of parent classes in the FPDI & TCPDF libraries, in particular a conditional inheritance in fpdi_bridge.php. The condition is class_exists('TCPDF', false). This should always be true, but if it evaluates false the code will extend class FPDF instead of TCPDF, and in that case getCellHeight() won't exist.
But it doesn't make sense that the evaluation should fail; the libraries are all loaded at the start of views_pdf_template.php, and class FPDF doesn't exist either, so an attempt to extend that should result in an immediate error.
I'm wondering if it could be a PHP problem with available RAM. The whole of views-pdf drags in a large amount of code, so in a marginal case could lack of RAM result in strange behaviour rather than actual out-of-memory errors?
Can I suggest checking the server configuration and upping the max. memory allocation if possible?
This sounds like a complex interaction, and hard to determine which module is actually at fault.
Which version of user-revision are you running? The version 1 line hasn't received much work for a long time. If you're still on that version I recommend trying 7.x-2.x dev (which needs to be released as 7.x-2.1 - must do that).
Hi Miguel
That's great to hear, I'd almost forgotten about that bug! Good to know it's sorted the problem.
I'd recommend installing the patch, it simply changes the default format for a new PDF view to Table, so that you have to switch to use Unformatted, and that fixes the initialisation issue. Helps avoid the frustration you've just experienced!
I will commit the patch to dev shortly, I think it's worth RTBC.
I will close this issue now.
It's just occurred to me this could be a manifestation of issue 🐛 Pdf content until "pdf unformatted" format is set for secont time Fixed .
If so, then simply switching the display format to table or grid, and switching it back again, will fix it. The patch in that issue fixes the problem for newly created PDF views, but won't fix an existing one. Switching the format sorts it out.
Please give it a try and let me know.
Please see the Readme help fiile re. customising the profile title.
In addition, revision 7.x-2.0 allows even more flexibility, the title can be editable if a separate page is enabled for the profile.
Hmm, I'm confused. We both seem to have created the equivalent view with the same versions of software, but with different results. I really don't know where to go next.
Version of webform? I'm using 7.x-4.25, not sure that would make any difference though.
I'll have to have a think as to how to solve this.
Could you attach an export of your view?
Strange!
Do you get a value for the field on a preview of the master tab?
What version of TCPDF are you using? I have 6.3.5, some earlier versions have issues with PDP 8. I've just checked github, and the latest is 6.6.2!
I've done a very simple test and it works OK.
I installed the latest webform (7.x-4.25), created a webform node, then created a form with a single text field, and created a submission.
I then created a view of type "webform submission", added a webform data field, which offered me the one form field I'd created. This is all on the master tab. The preview showed the value I'd submitted.
Finally I added a PDF Page tab, gave it a path (no other changes), invoked the path and got a PDF with the field data displayed. This worked with all three PDF formats.
The only thing I can think of is if you're using the view that was created under views-PDF 7.x.1.x, and have not updated any settings, there may be rendering issues. I suggest first try changing something so you can re-save the view. This will update the internal settings which may fix the problem. If that doesn't work, please try re-creating the view from scratch.
Let me know the results - thanks.
OK, thanks. I don't use webform live, only experimented a bit with it. I'll see what I can do to work out what's changed to affect the behaviour. May take a little while ...
Which version exactly were you using previously?