The filter stops working if there is an element with a class in the content after the table. If elements with classes are before the table everything works fine.

Comments

alphasupremicus’s picture

I have a table where the first cell in the first row has the class "rteright" (put there by ckeditor when I right-aligned the cell) and, if that's the case, then this filter just avoids adding the odd or even class to the row. Basically, I can't seem to put any class on the first cell of any row it this filter doesn't format that row. Is this expected?

Again, I am only using the CKeditor which places a right alight class on the cell so I can format up the table. If I place right align classes on the second cell, then the row is still stripped properly with odd/even classes. Seems odd to me that this is a "first-cell in the row" only problem that causes this.

alphasupremicus’s picture

Attached is a simple patch that removes the check for class and just goes ahead and applies the even/odd closs to the TR element. I think the intent of the author was not to blow over the class of the TR row and just disregard applying the even/odd classes if the TR row had a class="something" already, but it turns out that the code is instead finding the class setting of my TD (cell) and is also skipping the entire row if my TD has a class.

There must be a better way to solve this - for now I just provide a patch that stops checking for "class=" and this fixes it for my site.

pheraph’s picture

Same here. Your patch may be a temporary fix but it would be nice if the module handled additional classes.

alphasupremicus’s picture

Understood. I didn't have time to add new features. I just wrote a patch to make this module behave consistently. I thought it was odd that there was a check for the first cell only in each row. If the first cell had a class then it punted and didn't apply the odd/even style. But the module didn't care if there were classes applied to the second, third, ... n cells in the row. So I find that inconsistency to be a bug myself.

John

Anonymous’s picture

Title: Filter doesn't work if elements after table have classes » Filter doesn't work if other elements have classes
Version: 7.x-1.2 » 7.x-1.x-dev
Status: Active » Needs review
StatusFileSize
new670 bytes

This patch is slightly better in that it only checks for the 'class' attribute within the TR tag - it ignores classes in other tags (e.g. TD).

Unfortunately my regex is not strong enough to work out how to append classes instead of overwriting them...

xaa’s picture

hi, thank you for the patch. seems working as expected.
Will be great if it can be commit soon.

regs, xavier

samvel’s picture

Issue summary: View changes
StatusFileSize
new1.43 KB

Hi Guys,

appended patch, now other classes in

were kept.

Please review, thank you.

samvel’s picture

Up!

runnergirl’s picture

I tried the patch suggested by Samvel (comment #7) and it worked for me. In my case, I have two tables, in which only the second table was displaying with the odd/even row classes. After applying the patch, the first table then displayed as it should. Thank you Samvel for posting this patch.

johnpitcairn’s picture

This patch works for me on a page with multiple tables that have class and data attributes on the table elements set by another filter. Without the patch, the odd/even row classes are not set.

I didn't test that existing row classes are preserved however.

johnpitcairn’s picture

Status: Needs review » Reviewed & tested by the community

I can confirm that existing row classes are preserved. Marking RTBC.

  • deviantintegral committed 0bf201c on 7.x-1.x
    Issue #1209858 by alphasupremicus, Samvel, BWPanda: Filter doesn't work...
deviantintegral’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Thanks, I've committed #7.

astonvictor’s picture

Since the patch was merged, I guess we can close the issue.

astonvictor’s picture

Status: Patch (to be ported) » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.