This is a follow-up issue of #1914024: Title-overriden term name not translated on a taxonomy overriden views page.

Since this change I got an undefined index "machine_name". I debugged that and it seems that we cannot use machine_name when using entity load. When you load a term programatically there is no machine_name and you have to use vocabulary_machine_name instead.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yannickoo’s picture

Status: Active » Needs review
FileSize
839 bytes
caktux’s picture

Works here, had a view with a "Has taxonomy term ID" contextual filter validating the term ID that was disappearing because of this.

2faroffroad’s picture

Confirmed working also.
Thanks for finding a solution.

Infinitee’s picture

Verified ... Works for me.

Thanks!

dawehner’s picture

This doesn't seem to be the only place for machine_name is used on that file?

yannickoo’s picture

But this is the only time where the machine name comes from the loaded term. At the other places the database table column will be used.

yannickoo’s picture

The machine_name field from database is no longer needed.

dianacastillo’s picture

This happens with the new version of views. I went back to the old version of views and dont get this error any more - to be more clear, when I upgraded to 7.x-3.6 version of Views my views stopped working and I got this error Undefined property: stdClass::$machine_name in views_plugin_argument_validate_taxonomy_term->validate_argument()
I went back to 7.x-3.5+42-dev and they work again.

this is the exact error I got Notice: Undefined property: stdClass::$machine_name in views_plugin_argument_validate_taxonomy_term->validate_argument() (line 108 of C:\Program Files (x86)\Apache Software Foundation\Apache2.2\htdocs\pn\sites\all\modules\views\modules\taxonomy\views_plugin_argument_validate_taxonomy_term.inc).

pierrozone’s picture

Patch #1 Works for me :)

presleyd’s picture

Patch #7 worked for me.

Geijutsuka’s picture

Patch #7 worked for me.

DanZ’s picture

roderik’s picture

Priority: Normal » Major
Status: Needs review » Reviewed & tested by the community

And #1948646: Product page (taxonomy term page) - Commerce site was closed too. Which was already set RTBC. #5 was addressed by the comment with that patch. It's cut and dried.

A completely broken taxonomy term argument isn't peanuts. The status is at least major. (It actually fits the description text for critical.) Lots of people's sites are breaking especially because they are being told to upgrade to a security release, and then their pages and blocks disappear without a trace.

@yannickoo thanks for spotting the unused SQL query field, I/others hadn't done that.

Joefry’s picture

Thanks! patch #1 solved the problem for me.

dawehner’s picture

Status: Reviewed & tested by the community » Needs work

Let's get this in, but please let us use taxonomy_term_load in all the places, if possible.

yannickoo’s picture

All places? Do you mean only in the one file?

It is used on line 105, 154 and 188.

Which places do you mean?

yannickoo’s picture

Where can I find this in Drupal 8?

roderik’s picture

Status: Needs work » Needs review
FileSize
3.33 KB

@dawehner: I don't get what you mean, either. Seems to me that taxonomy_term_load() is used where it should be. I assume #1914024: Title-overriden term name not translated on a taxonomy overriden views page took care of that.

I'm just guessing at the reason for your remark: is it the inconsistency (& fear of possible further confusion) between 'machine_name' and 'vocabulary_machine_name'? That can't be solved by using taxonomy_term_load() everywhere, because in some places there are no terms to check -- there is only a vocabulary.

What could be done, is to always check the database query result, never the term (so you never need to use vocabulary_machine_name) -- as per the example patch. I removed any use of $term for a database result/row, but only from this file. (The first hunk contains the functional change/fix; the rest is just renaming.)

But again, I'm just guessing at your desired outcome.

Status: Needs review » Needs work

The last submitted patch, 1949178-18-justguessing.patch, failed testing.

roderik’s picture

Status: Needs work » Needs review
FileSize
3.5 KB

LOL, never mind, fix was already committed :)

Rerolled, but feel free to ignore/close if you want.

millionleaves’s picture

Thanks. Was experiencing this issue in Ubercart after upgrading to View 3.6. Now fixed with the patch in #7.

kap316’s picture

No matter how hard I try.. I can not figure out how to apply patches.. So situations like this, I am screwed. I have no Store anymore! How in the world can I fix this without knowing how to patch. Trust me, I tried a ton and I simply can't grasp the way to patch.

wxman’s picture

Thank you. I'm using 7.x-3.6 and couldn't figure out where these errors were coming from. The patch in #1 worked.

millionleaves’s picture

kap316 - I wrote a simple guide to patching Drupal on Linux here . Hopefully that helps. Private message me if you get stuck rather than discussing it here.

DanZ’s picture

Status: Needs review » Fixed

The fix in #7 was committed at http://drupalcode.org/project/views.git/commit/a6fdcd6.

I could be wrong, but I think dawehner just set the wrong status in #15.

If there is further work to be done, I think you're supposed to make a new issue, right?

Also, is there going to be an immediate new release? I think the bug is disruptive enough that it would be worth it. Not everyone knows how to find and apply a patch or a -dev file to fix something like this.

dawehner’s picture

Status: Fixed » Needs review

@Danz

*sighs* The patch was committed but I asked for a small follow up. I don't care whether it's done here or somewhere else, but if you close an issue please
also create a new one.

I'm not sure whether a NOTICE is a reason for a release, even this happens on a lot of sites :(

We could drop the follow up for D7 but we certainly should fix it properly on D8.

roderik’s picture

@dawehner:

It's your issue to review, no? You haven't specified your definition of 'properly' / answered what you mean with #15. Noone else can do that for you because we can't look inside your head.

The issue is fixed 'properly' as far as I can see; if it is not, according to you, please enlighten us.

Also: It surprises me that this was not clear yet but this is not just a NOTICE issue. People's views outputs are disappearing left and right, because the taxonomy term argument plugin is broken, so they get no results back. This is a critical issue, if not major.

roderik’s picture

@kap316: reinstall version 3.5.

mdvannoort’s picture

Version: 7.x-3.x-dev » 7.x-3.6

after applying #1 and #7 I get: Notice: Undefined variable: term in views_plugin_argument_validate_taxonomy_term->validate_argument()
in line 95 of the same file and:
Notice: Trying to get property of non-object in views_plugin_argument_validate_taxonomy_term->validate_argument() also in line 95 of the same file
what do I do now?
Oh, by the way the Ubercart products are displayed now, but not a nice 'view' those red blocks on your product pages

dawehner’s picture

Status: Needs review » Needs work
It's your issue to review, no? You haven't specified your definition of 'properly' / answered what you mean with #15. Noone else can do that for you because we can't look inside your head.

Yeah I should review the code, but there is no reason that it's not the job of all other people to look at the code, just saying.
Every release is a perfect source for a burnout, sorry.

So let's not clean this stuff up in d7, but just fix the bugs.
@mdvannoort
Are you sure you managed to apply the patch right? Line 95 of the dev version, doesn't have $term in line 95.

Leeteq’s picture

IMO, this calls for a 3.7 release.

dawehner’s picture

There is a critical component sometimes, which is called time, maybe you have heard of issues with it :)

fonant’s picture

Patch #7 works for me, and fixes a major problem of a missing taxonomy_menu menu.

mdvannoort’s picture

Thanks for answering dawhener
I'm using 3.6, not the dev version, didn't know where else to post.
Should I install the dev version or go back to 3.5 version?

Marty2081’s picture

The dev version of the module fixes the issue in my case.

yannickoo’s picture

Status: Needs review » Needs work

@mdvannort just use the dev version of Views :)

roderik’s picture

Status: Needs work » Needs review

Yeah I should review the code, but there is no reason that it's not the job of all other people to look at the code, just saying.

I agree, but:

Every release is a perfect source for a burnout, sorry.
So let's not clean this stuff up in d7, but just fix the bugs.

The bugs are already fixed and committed! We're going in circles here.

Noone here knows why you put back the issue to 'needs work' in #15! I don't, yannickoo doesn't. You didn't explain it. I'd like to offer my help in this issue, but I need to know what to help on.

(And why you are now setting it back to 'needs work' while there is even a patch for review already, is beyond me.)

I appreciate everything you are doing here, 'shit happens', and I don't like to get on your case, but I don't know another way to extract the answer as to why this bug was set to CNW. And it's safe to assume lots of people's Dupal installs are breaking every day, so iMHO this warrants a new release too. The -dev version is fixed already. We're just stalling things here, and I don't understand why and how to move forward.

DanZ’s picture

Status: Needs work » Needs review

Roderick wrote:

Noone here knows why you put back the issue to 'needs work' in #15!

Maybe we can figure it out. In #15, he wrote:

but please let us use taxonomy_term_load in all the places, if possible.

I'm not sure what that means, but maybe that's asking for a further fix to current code?

mikeinvaldosta’s picture

Thank you! #7 appears to resolve issue for me

roderik’s picture

@DanZ: I got that far.

My answer to your last suggestion (in the form of a proposed fix, and "maybe this is what you mean?") was posted in #18. (Patch against 3.6 in #18; patch against HEAD in #20.)

IMHO #20 is the situation where we still are. I'm open to comments on that. From anyone (hence 'needs review').

(AFAICS, taxonomy_term_load is "used in all the places" c.q. that is not an issue that should be fixed. My patch only addresses another thing in the code that eases possible misunderstandings which caused the bug, though it's not a functional change and its importance is up to debate.

That's all the suggestion I can think of. If someone else can figure out "let us use taxonomy_term_load in all the places", please let us know.)

dawehner’s picture

Status: Needs review » Fixed

The bugs are already fixed and committed! We're going in circles here.

I was talking about loading the other terms via entity load as well, so yeah let's mark the issue as fixed and that's it. I don't want to waste more time here.

PS: Is it just me that writing in strong is really confusing?

DanZ’s picture

PS: Is it just me that writing in strong is really confusing?

It's not just you. It has to be used very sparingly. Boldface is typically used for titles/headings, and the <h1>, <h2>... headings typically do that automatically. If you really must use it in some sort of body text, allow yourself three words of <strong> per year. Once you've used up all three, you can't do it again until January, so choose carefully.

Standard style is to use <em> for emphasis. Even that is somewhat of a crutch. Try to choose words that emphasize what needs to be emphasized, without typeface tricks.

While we're on the subject, never use <u> (underline), and only use <blink> if you want to get slapped. In the face. Hard. By total strangers. Lots of them. Because you deserve it.

mxh’s picture

:D made my day.

1mundus’s picture

Confirming that the current dev release fixes this bug. IMHO this is definitely a critical bug - none of the taxonomy terms outputted through Views were working and it broke half of my site. Such fixes should be a part of an official release as soon as possible since it seems that there are many of us affected.

dianacastillo’s picture

yes especially since Drupal keeps giving you messages "There are security updates available for one or more of your modules or themes. To ensure the security of your server, you should update immediately! " and if you update the views module which is what it's talking about, your views stop working!

kamenrs’s picture

#7 resolved the issue for me. Thank you!

Johnxystus’s picture

Patch #1 works at first; but then my views fails even if there's no Relationship argument / taxonomy fields used. So i did patch #7 - still didnt work for me ... Im downgrading to 3.5

zzlalani’s picture

Status: Fixed » Needs review
dianacastillo’s picture

Since there seem to be so many untested problems, why dont you put back the recommended release to 3.5 so that people doing new installations of views will have a working version?

Chewie’s picture

#18: 1949178-18-justguessing.patch queued for re-testing.

yannickoo’s picture

Why do you re-test all these patches? o_ô

markabur’s picture

Status: Needs review » Fixed

With Views 3.6, my taxonomy views were all coming up blank, and with Views-7.x-3.x-dev 2013-Mar-23, my views are working again. So, back to "fixed"

dianacastillo’s picture

Status: Fixed » Needs review

How can this be marked fixed when the 7.3.6 version which doesnt work still is marked as the recommended version?

2faroffroad’s picture

Status: Needs review » Fixed

Can we all just get along...

@dianacastillo
- install the dev version and report back if you still have problem. if not then its fixed.

They are not marking 7.x.3.6 as fixed.. only marking the issue with a confirmed fixed.
leaving it in yellow or red means there is not a proper fix.
green means there is a fix and you should use it.

A release will come in time.
But I do agree then should update the dev to the recommended version.
However there are other issues in the dev that need to be addressed before it can be released.

Leave it fixed unless you find a different problem.
And when you find a new issue --> start a new ticket.
Thanks.

dianacastillo’s picture

I'm worried about all of the poor people who are just starting with Drupal 7 who will install a views module that doesnt work since the recommended one has so many bugs.

I dont want to risk using the dev version either since #47 found problems with that one also. I am staying with 3.5 version

jghyde’s picture

I have successfully upgraded my views to 7.x-3.x-dev 23 Mar 2013 edition, assuming it's with the patch(es) disputed above.

All tests quite well on views with or without taxonomy contextual arguments.

It's all good!

Thank you and good day!

liquid06’s picture

When can views users can expect a stable 7.x-3.7 release that includes this fix?

ilfelice’s picture

FWIW, 7.x-3.x-dev 23 Mar 2013 edition is working here on a Drupal 7.21 installation.

abx’s picture

Tested dev version 23 Mar 2013 and it works ok now

dimitrisg’s picture

Thank you it solved the problem BUT

1) On the top of the page shows this part of the code :

"diff --git a/modules/taxonomy/views_plugin_argument_validate_taxonomy_term.inc b/modules/taxonomy/views_plugin_argument_validate_taxonomy_term.inc index ba1a0e7..1c9e0e4 100644 --- a/modules/taxonomy/views_plugin_argument_validate_taxonomy_term.inc +++ b/modules/taxonomy/views_plugin_argument_validate_taxonomy_term.inc @@ -105,7 +105,7 @@ class views_plugin_argument_validate_taxonomy_term extends views_plugin_argument } $term = taxonomy_term_load($term->tid); $this->argument->validated_title = check_plain(entity_label('taxonomy_term', $term)); - return empty($vocabularies) || !empty($vocabularies[$term->machine_name]); + return empty($vocabularies) || !empty($vocabularies[$term->vocabulary_machine_name]); case 'tids': // An empty argument is not a term so doesn't pass."

2) My catalog name has turned into "NO NAME". How can I change it?

Any solutions?

Thanks!

gittosj’s picture

Just installed 7.x-3.x-dev on 7.21 and views are back working again

rokk’s picture

Also worked for me!

Thanks ;)

i92guboj’s picture

Indeed, this completely broke my online shop a few hours ago. Fortunately the log was clear enough for me to figure out this.

jackhutton’s picture

Thank you for this issue chain; Installed the 7.x-3.x-dev version which addressed the error noted in the subject.
Appreciate all of your work.

lyricnz’s picture

I had this bug also. Very annoying, especially since 7.x-3.6 was a security fix, and was hence applied a little more hastily than a fix/feature release.

Asgarden’s picture

Status: Fixed » Needs review
DanZ’s picture

Status: Needs review » Fixed

It doesn't need to be re-tested. #7 is already committed.

dimitrisg’s picture

Status: Fixed » Needs review
dawehner’s picture

Status: Needs review » Fixed

/me sighs

yannickoo’s picture

Yeah, already 70 comments, wtf...

dimitrisg’s picture

Can someone tell me the steps how I can use this patch in order to work?

yannickoo’s picture

I would recommend to download the development version of Views but you also can apply the patch manually:

git clone --branch 7.x-3.x http://git.drupal.org/project/views.git
cd views
wget http://drupal.org/files/views-vocabulary_machine_name-1949178-7.patch
git apply views-vocabulary_machine_name-1949178-7.patch
rm views-vocabulary_machine_name-1949178-7.patch
DanZ’s picture

Downloading the -dev version (with git clone) and then trying to apply the patch to the -dev version won't work. The -dev version already has the patch.

Hemptopia’s picture

I am getting this same error message: Notice: Undefined property: stdClass::$machine_name in views_plugin_argument_validate_taxonomy_term->validate_argument

What can I do to fix?

DanZ’s picture

Apply the patch in #7 or install the -dev version of the module.

dimitrisg’s picture

How I can dowload the views -dev version????

Stolzenhain’s picture

@dimitrisg: Visit the Download section of the project page; you find the mentioned download under "Development releases".

Anonymous’s picture

Hi, someone could help me?

I have my drupal site on a host and i have windows. How can i patch my site?

Thanks,
Klain

jessicakoh’s picture

@Klain You can use the dev version.

2faroffroad’s picture

@dawehner
I am starting to agree with some of these guys....
Frustrated because they were notified to update there fully functioning site just to break it.
Its been 2 weeks and the recommended version is still a defunct one!!!
What is stopping the Views team from releasing a "WORKING recommended" release?
Please help the Drupal community who have crashed there sites from this issue by releasing 3.7.. or at least 3.61.
Thanks for your time.

dianacastillo’s picture

maybe Views isnt considered an important module :-)

Johnxystus’s picture

Hi guys,
i upgrade to core 7.22 and update to ctools 7.13, rules 7.23 and views 7.36 - everything looks OK so far on my local machine. but im too scare to update my production site. anyone out there can confirm this or has updated and find no problem?

thanks.

dianacastillo’s picture

Well if you do a fresh install of Drupal you get this version of views which has a lot of bugs. Perhaps the views team is being paid off by Microsoft?

mxh’s picture

Johnxystus, I can speak for my production sites that the current dev version works well. I have a lot of views which are using taxonomy contextual filters, numerous complex queries, which all work fine (so far). There is never a guarantee that it's also working on your sites. Just test it out on a development environment. I don't recommend you to use version 3.6.

dawehner’s picture

@dianacastillo
I really hope that this was a sarcastic comment. Thank you for appreciating other peoples freetime. Next time I will better sit in the park reading a book instead of working, actually that's a great idea!

Here is a list of bugs the views team hasn't fixed yet: http://drupal.org/project/issues/views?categories=bug

wickus’s picture

Installed the dev version...it works now. Thank you very much :)

Btw. when I tried to install the dev version through the module page downloading the update directly from the drupal page to my site, it gave me the message that views is already installed (My last views version was the one causing the trouble). Is this normal?
I then emptied the views folder per FTP and uploaded the module there.

Geijutsuka’s picture

That's definitely normal, wickus. Your Drupal install only knows about the latest stable release and won't tell you about dev versions of modules (even if the dev version fixes a problem with the stable release). You did the right thing by finding the problem in the issue queue and downloading the development version.

vendyatelier’s picture

Status: Fixed » Needs review
dawehner’s picture

Status: Needs review » Fixed

@vendyatelier
That patch got committed already a long time ago, so there is no reason to set it to needs review.

dimitrisg’s picture

@Paracetamol thank you!

Johnxystus’s picture

@hauptm thank you ..

dianacastillo’s picture

yes that was a sarcastic comment. but I still worry for people who are new to drupal 7 and wont know that they have to read the issues before they install the recommended version. Cant you put a note on the front page of the view issue that explains this?

jessicakoh’s picture

@dianacastillo Try look yourself in the mirror. Ask nicely.

However, I do agree with her that a notice or warning need to be posted for V3.6.

dianacastillo’s picture

I think I was asking nicely. Anyways, its not for me , i already know not to install the recommended version, its for the community that I was asking.

Leeteq’s picture

IMO, it is bad that such a bug will hit newcomers and others who are not up to date on this issue, especially taking into account how many other contrib. modules that rely and refer to Views.

I think that a 3.7 release should simply consist of 3.6 plus only this fix, alternatively any other major/critical 3.6-related _fixed_ issues.

If that is not possible, then tag 3.6 as unstable with red color and post a link to this issue on the project page, and promote 3.5 as the recommended/green release as @dianacastillo suggested way back in #49, until we have a (new) stable release.

I truly appreciate and respect the hard (voluntary) work of the Views team and their obvious time constraints, but in this particular case we are not talking about the time it takes to fix enough bugs to make a new stable release, but rather either put the recommendations back to 3.5, or only include one patch in a new release. That is not a lot of work.

dawehner’s picture

yannickoo’s picture

Status: Fixed » Closed (fixed)

No more comments are necessary here because of the new release.

dimitrisg’s picture

How do I install the -dev version of views?

DanZ’s picture

How do I install the -dev version of views?

Don't bother. Just use the new 7.x-3.7 release, which has the fix for this issue.

If you really want to use the -dev version, just download the 7.x-3.x-dev archive from the project page or from http://ftp.drupal.org/files/projects/views-7.x-3.x-dev.tar.gz and install it like any other module.

StephenRobinson’s picture

ditto, i can select all and it works, as soon as i filter by one of the other options, whatever option i select apart from all, it goes back to this first selection

StephenRobinson’s picture

tried 4,5,6,7 - answer is - disable caching on view, then all fine with 3.7

StephenRobinson’s picture

bottom line - use exposed taxonomy filter = don't cache the view.