Pager returns to the first page after save
duckzland - May 31, 2009 - 08:21
| Project: | Translation table |
| Version: | 6.x-1.x-dev |
| Component: | User interface |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | fixed |
Jump to:
Description
When I am using the 1.0-beta1 version, the pagination works and displayed on the bottom page of the translation table page, but the bug is when the next button is clicked sometimes its display an error complaining about url is too long (apache error page).
Now, after upgrading to 1.0-rc1 the pagination is missing, and only display the first page of the translation table content.
I really like the module since it's cuts down the time needed to do a full translation for a drupal site, but this fatal bug is rendering the module useless.
cheers,
duckz
#1
the limit was increased to 50, so there are now 50 items on one page. How many items do you see?
#2
yes, the pager is not rendered
#3
#4
Yes I got exactly 50, as I know it is supposed to be more.
Should I use the dev version to resolve this?
Thanks.
#5
it's not fixed yet. The issue is harder than I first thought. Will try to fix it this week..
#6
Hi Pasqualle, Any news about the fix for the missing pagination?.
#7
subscribed
#8
http://drupal.org/cvs?commit=223404
should be fixed, please test the next dev release
#9
I tested the 10 june dev version, the result:
The menu translator did show the pager.
The content type didnt show any pager, I don't know if this is by design or not as I don't know if this is supposed to list content type or built-in interface?.
If it supposed to view built-in interface then the pagination is not working but if this is just for content type then I supposed it works or I dont have enough string for content type to show pagination.
My translation overview status :
Built-in : 6293/9572 (65.74%)
Content-type : 0/43 (0%)
Is it possible to have another tab for built-in translation string search?
Anyway, Thanks for the great module, I can translate the menu in a breeze now.
Duckz
#10
the pager is only shown with list which have more than 50 items..
the string search is in Drupal core, and I do not plan to duplicate functionality.. But if you have a suggestion for improvements (like putting a link somewhere for the search), then please create a new feature request..
#11
well I guess the module is working perfectly then, I know the drupal string search capability but as you may also know its a pain in the neck to use not to mention the bandwidth wasting overhead to refresh every string that user wish to translate :) . if they implemented nice translate box in every string like your module it would be a great feature.
#12
The pagination in rc2 works great, except that after clicking "save" I am always returned to the first page of results.
#13
I am not sure if I can fix that. The pager works same as pagers on other admin pages..
#14
#15
You say it works the same as pagers on other admin pages, but it clearly does not because it returns to page 1 when you save your form when other forms stay on the current page. Have you even tried saving other forms in Drupal? If every pager in Drupal did indeed return to page 1 after you saved the form then usability would be nearly nonexistent for those with more than 1 page.
If you had looked into this issue yourself instead of saying it probably can't be fixed you would quickly notice that other forms have this line of code:
$form['destination'] = array('#type' => 'hidden',
'#value' => $_GET['q'] . (isset($_GET['page']) ? '?page='. $_GET['page'] : '')
);
whereas your form does not.
By just adding this line to your code it returns the user to the page he was on when he submitted the form.
I just hacked this into the translation_table_taxonomy_filtered_form() function on line 143 of admin.inc because that was were I noticed this problem, but seeing as you have more forms in your module you probably want to add it to those as well.
#16
@TwiiK: thanks for the help, but please save me from your judgment in the future.
http://drupal.org/cvs?commit=292356
#17
@Pasqualle: I believe you'll need to call check_plain on $_GET['q']. And thanks again for a very useful module.
#18
@mvc: why do you think it needs a check_plain? As I see the $_GET['q'] is used without check_plain in Drupal and contrib modules..
#19
$_GET['q'] is exactly what the user sent as a request, and may contain quote characters and so on. In this case I believe you'll be taking that information and inserting it into the form, thereby allowing users to place arbitrary HTML on the page. If user X is tricked into visiting a page containing arbitrary HTML by user Y, they could run javascript written by Y and placed in the URL, which is a security issue. It wouldn't be as bad if you were just doing drupal_goto($_GET['q']) .
#20
as I know the redirect is doing a drupal_goto(), and does not place it into the page..
#21
Sorry, Pasqualle, you're right. Drupal is smarter than that. Never mind, and thanks again for this very practical module.