I have been using the CCv5 plugin embedded in an article and have been passing a parameter. I have created a simple example to illustrate the SQL Error I am getting.
In this example I read from the Weblinks table and display the catid and title fields. In the article's plugin reference I pass the catid to the CCv5 connection:
{chronoconnectivity5}PaginationError&catid=21{/chronoconnectivity5}
The Model uses the following condition code:
<?php $catid = \GCore\Libs\Request::data("catid"); return array (":newsletters.catid = {$catid}"); ?>
The initial display looks like this:
[attachment=0]PaginationError Initial Article Display.PNG[/attachment]
Using the navigation arrows or numbers does not cause an error, but changing the items per page does.
When I change the value in the dropdown from 30 to 10 the following error appears:
[attachment=1]PaginationError Change Dropdown to 10 per page Error.PNG[/attachment]
If I then go back and change the condition to add a default value for the catid using the following:
<?php
$catid = \GCore\Libs\Request::data("catid");
if(empty($catid)) {$catid=24;}
return array (":newsletters.catid = {$catid}");
?>
There is no SQL Error, but the catid used is the default value and not the plugin passed value:
[attachment=2]PaginationError Change Dropdown to 10 per page Default Used.PNG[/attachment]
So, it appears that when Items Per Page is changed, the condition when executed in that part of the Pagination code does not find the value of the Plugin passed Parameter. The SQL error occurs because the $catid value is empty. Once a default statement is added, it is used avoiding the SQL error.
How can I fix this issue?
Where do I look in the CCv5 code?
This is the same issue as seen in this post:
http://www.chronoengine.com/forums/posts/f13/t98583/ccv5-plugin-passed-parameter-sql-error-on-delete.html
This is causing me problems that I need to fix very soon!
In this example I read from the Weblinks table and display the catid and title fields. In the article's plugin reference I pass the catid to the CCv5 connection:
{chronoconnectivity5}PaginationError&catid=21{/chronoconnectivity5}
The Model uses the following condition code:
<?php $catid = \GCore\Libs\Request::data("catid"); return array (":newsletters.catid = {$catid}"); ?>
The initial display looks like this:
[attachment=0]PaginationError Initial Article Display.PNG[/attachment]
Using the navigation arrows or numbers does not cause an error, but changing the items per page does.
When I change the value in the dropdown from 30 to 10 the following error appears:
[attachment=1]PaginationError Change Dropdown to 10 per page Error.PNG[/attachment]
If I then go back and change the condition to add a default value for the catid using the following:
<?php
$catid = \GCore\Libs\Request::data("catid");
if(empty($catid)) {$catid=24;}
return array (":newsletters.catid = {$catid}");
?>
There is no SQL Error, but the catid used is the default value and not the plugin passed value:
[attachment=2]PaginationError Change Dropdown to 10 per page Default Used.PNG[/attachment]
So, it appears that when Items Per Page is changed, the condition when executed in that part of the Pagination code does not find the value of the Plugin passed Parameter. The SQL error occurs because the $catid value is empty. Once a default statement is added, it is used avoiding the SQL error.
How can I fix this issue?
Where do I look in the CCv5 code?
This is the same issue as seen in this post:
http://www.chronoengine.com/forums/posts/f13/t98583/ccv5-plugin-passed-parameter-sql-error-on-delete.html
This is causing me problems that I need to fix very soon!
I was able to make a temporary workaround to get this working properly.
The approach I took was to add the passed parameter catid to the $session and code to retrieve it from there if it was not set in Request::data:
[attachment=0]GCore-Libs-Base getSession Condition.PNG[/attachment]
I feel this is not an appropriate long-term solution to this problem. I thought about modifying the plugin code to automatically put the passed parameters into the Session, but decided against it. I will just use this approach until you are able to identify an appropriate permanent fix.
The approach I took was to add the passed parameter catid to the $session and code to retrieve it from there if it was not set in Request::data:
[attachment=0]GCore-Libs-Base getSession Condition.PNG[/attachment]
I feel this is not an appropriate long-term solution to this problem. I thought about modifying the plugin code to automatically put the passed parameters into the Session, but decided against it. I will just use this approach until you are able to identify an appropriate permanent fix.
Please try to add a hidden field to the "header" section and name it "catid".
You may also try to add "catid" to the "stored fields" box under the listing settings!
Regards,
Max
You may also try to add "catid" to the "stored fields" box under the listing settings!
Regards,
Max
I tried the approaches you suggested, and resolved on using the following approach:
I simplified the condition to:
[attachment=0]Pagination Error Model Condition.PNG[/attachment]
and added the catid to the Front List Stored Fields:
[attachment=1]Pagination Error Front Saved Fields.PNG[/attachment]
This seems to be work just fine so far.
I would like to see the plugin passed parameters to be automatically stored in session and available as something like $params['catid'] where catid was passed in {chronoconnectivity5}PaginationError&catid=21{/chronoconnectivity5}
Thanks for your assistance.
I simplified the condition to:
[attachment=0]Pagination Error Model Condition.PNG[/attachment]
and added the catid to the Front List Stored Fields:
[attachment=1]Pagination Error Front Saved Fields.PNG[/attachment]
This seems to be work just fine so far.
I would like to see the plugin passed parameters to be automatically stored in session and available as something like $params['catid'] where catid was passed in {chronoconnectivity5}PaginationError&catid=21{/chronoconnectivity5}
Thanks for your assistance.
This topic is locked and no more replies can be posted.
