No Code Attached Yet
avatar jarea1050
jarea1050
4 Aug 2015

Steps to reproduce the issue

This has been tested using both Sorcerer and DirectPHP to embed php (and thus SQL) code in the body of an article. Same effect with either plug-in.

1) Place SQL code (preferably an Insert, but Select works as well) in an Article body, execute the Article and confirm that the SQL works.
2) Place the Article in a Category and place the Category List in a Menu item.
3) Display the menu.

Expected result

Simple listing of the Category items.

Actual result

Simple listing of the Category items AND
All of the SQL statements that are embedded in the Articles that are included in the Category list will be EXECUTED when the Category List is displayed!!!

System information (as much as possible)

Joomla 3.43
Sourcerer 5.0.0
PHP 5.4.42
MySQL 5.5.42

Additional comments

SQL Statement in 1st Article Body (Test Select)(encapsulated in Sourcerer tags)

{source}<?php
//$db = JFactory::getDbo(); / JFactory is not necessary with Sourcerer - it automatically creates the $db object
$query = $db->getQuery(true);

$query->select($db->quoteName(id));
$query->from($db->quoteName('test'));
$query->order('id DESC');
$query->setLimit('1');

$db->setQuery($query);
$results = $db->loadResult();

var_dump($results);
echo "<br>ID is: " . $results;
echo "<br>New ID is: " . $results += 1;
?>{/source}

Alternatively, you can do a file include with the same effect.

SQL Statement in 2nd Article Body (Test Insert)

{source}<?php

// Test - insert a record into test table (id date_time text) not part of Fabrik universe

$date = JFactory::getDate();

// Get a db connection.
$db= JFactory::getDbo();

// Create a new query object.
$query = $db->getQuery(true);

// Determine the value for the next record

$columns = array('date_time', 'element');

$values = array($db->quote($date), $db->quote("sample text"));


// Build the query

$query

     ->insert($db->quoteName('test'))

     ->columns($db->quoteName($columns))

     ->values(implode(',', $values));



// Execute the query

$db->setQuery($query);

$db->execute();

echo '<h3><p style="text-align:center">Your submission to the TEST table  has been received. <br>Thank you for helping out!</p></h3>';

?>{/source}

Display the Category List (in Debug Mode)

**Title**       **Author**      **Hits**    
Test Insert     **Written by Super User**   **Hits: 9**
Test Select     **Written by Super User**   **Hits: 38**

Selected SQL statements from display of Category List

**Query Time: 0.41 ms** **After last query: 14.63 ms**

INSERT INTO `test`
(`date_time`,`element`) 
  VALUES 
('2015-08-04 01:14:39','sample text')

**Explain**
**EXPLAIN not possible on query: INSERT INTO `test` (`date_time`,`element`) VALUES ('2015-08-04 01:14:39','sample text')**
**Profile**
**No SHOW PROFILE (maybe because there are more than 100 queries)**
**Call Stack**
JROOT/plugins/content/DirectPHP/DirectPHP.php(58) : eval()'d code:51
JROOT/plugins/content/DirectPHP/DirectPHP.php:58
JROOT/libraries/joomla/event/event.php:69
JROOT/libraries/joomla/event/dispatcher.php:160
JROOT/components/com_content/views/category/view.html.php:106
JROOT/libraries/legacy/controller/legacy.php:690
JROOT/components/com_content/controller.php:104
JROOT/libraries/legacy/controller/legacy.php:728
JROOT/components/com_content/content.php:16
JROOT/libraries/cms/component/helper.php:392
JROOT/libraries/cms/component/helper.php:372
JROOT/libraries/cms/application/site.php:191
JROOT/libraries/cms/application/site.php:230
JROOT/libraries/cms/application/cms.php:252
JROOT/index.php:45
[**Add xdebug.file_link_format directive to your php.ini file to have links for files.**]
**Query Time: 0.20 ms** **After last query: 1.95 ms**

SELECT `id`

  FROM `test`

  ORDER BY id DESC 
  LIMIT 0, 1

**Explain**
id  select_type table   type    possible_keys   key key_len ref rows    Extra
1   SIMPLE  test    index   NULL    PRIMARY 4   NULL    1   Using index
**Profile**
**No SHOW PROFILE (maybe because there are more than 100 queries)**
**Call Stack**
JROOT/includes/test_select.php:15
JROOT/plugins/content/DirectPHP/DirectPHP.php(58) : eval()'d code:1
JROOT/plugins/content/DirectPHP/DirectPHP.php:58
JROOT/libraries/joomla/event/event.php:69
JROOT/libraries/joomla/event/dispatcher.php:160
JROOT/components/com_content/views/category/view.html.php:106
JROOT/libraries/legacy/controller/legacy.php:690
JROOT/components/com_content/controller.php:104
JROOT/libraries/legacy/controller/legacy.php:728
JROOT/components/com_content/content.php:16
JROOT/libraries/cms/component/helper.php:392
JROOT/libraries/cms/component/helper.php:372
JROOT/libraries/cms/application/site.php:191
JROOT/libraries/cms/application/site.php:230
JROOT/libraries/cms/application/cms.php:252
JROOT/index.php:45

Note: there is a workaround for the end user until this gets fixed. Have an Article listed in the Category (NSN) with a call to the Article containing the SQL statements. Place the Articles containing the SQL code in a different Category (nsn-code) which (hopefully) never gets listed.

<?php
// Calling Article in NSN Category

echo "
      window.open( 'http://localhost:8888/joomla_test/index.php/nsn-code/72-test-insert', '_self');
   </script>
";

?>

Votes

# of Users Experiencing Issue
1/1
Average Importance Score
4.00

avatar jarea1050 jarea1050 - open - 4 Aug 2015
avatar mbabker
mbabker - comment - 4 Aug 2015

I would be more inclined to call that a bug in those plugins versus the core platform. The plugins alter the behavior of the text area and allow PHP code to be executed (something that core does not do at all).

avatar Bakual
Bakual - comment - 4 Aug 2015

I would even say it's the intended behavior of the sourcerer plugin, not even a bug.

Closing this issue as it's not related to core.

avatar Bakual Bakual - change - 4 Aug 2015
Status New Closed
Closed_Date 0000-00-00 00:00:00 2015-08-04 05:59:02
Closed_By Bakual
avatar Bakual Bakual - close - 4 Aug 2015
avatar Bakual Bakual - close - 4 Aug 2015
avatar nonumber
nonumber - comment - 4 Aug 2015

Best to do sql stuff via an include_once.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/7625.

avatar jarea1050
jarea1050 - comment - 4 Aug 2015

include_once does not resolve this issue. SQL still executes when displaying Category listings. If this is just normal operation of core then best to be aware of the situation when using PHP code wrapper plugins. The workaround does provide an effective way to avoid the unwanted effects.

avatar mbabker
mbabker - comment - 4 Aug 2015

The plugins are altering the core behavior, there isn't anything in core for us to change unless we completely remove the event system. Once you install plugins that allow you to run PHP code that's input in editor areas, what's done with it when that content is displayed is beyond the scope of what the core platform is responsible for.

avatar jarea1050
jarea1050 - comment - 4 Aug 2015

"what's done with it when that content is displayed is beyond the scope of what the core platform is responsible for."

I am willing to accept that this is normal operation of the core, but my problem is in this situation, the content in the article is not being displayed, only a listing of the titles of the articles. And when those titles are listed via a Category listing of Articles, the SQL embedded in each article in the category is executed. That seems out of bounds to me.


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/7625.

avatar mbabker
mbabker - comment - 4 Aug 2015

If the behavior can be reproduced with the core platform (no third party plugins), then with a good set of instructions on how to recreate the issue, it can be resolved.

If enabling a third party plugin alters the expected output, and it can be traced to the plugin as giving the unwanted behavior, the issue must be addressed by the third party plugin.

As much as I agree you're seeing behavior that isn't what you expect, the bug that you are seeing is one that is a result of a third party's action and cannot be resolved by the core platform. Because of how data objects are passed into the various plugin events, it is entirely possible for plugins to override certain data, add extra data, or remove it completely. Without proper checks in plugin code, it can have very unwelcome side effects; I know this first hand developing plugins and having to make them work not only with core but other plugins. It's a side effect of having such a powerful plugin system.

avatar nonumber
nonumber - comment - 4 Aug 2015

The issue - when getting to the Joomla core level - is that the category list view also collects the article contents and passes that through the plugins.
This is indeed useless, as it is not going to display that data.
This is a core issue as this results in slower page loads: data being collected and passed around plugins that isn't going to be used.

In the case of @jarea1050, this results in the issue with embed php being executed.
Other examples are plugin adding scripts and styles to the head because of plugin tags (like {foobar}) being found.

The solution for plugins would be to double check the context/url to see if it concerns a category list view and in that case not do its thing on the article contents.

The better solution is if core wouldn't be collecting and passing that data in the first place.

avatar Bakual
Bakual - comment - 4 Aug 2015

The solution for plugins would be to double check the context/url to see if it concerns a category list view and in that case not do its thing on the article contents.

Exactly that :smile:
And please check also the document type (format parameter) before adding scripts and the like. To many plugins run when not in HTML mode.

avatar Bakual
Bakual - comment - 4 Aug 2015

I am willing to accept that this is normal operation of the core, but my problem is in this situation, the content in the article is not being displayed, only a listing of the titles of the articles.

The problem is that this statement depends on the layout in use. While it is true for the "list" layout, it isn't true for the "blog" layout. And thus the view always prepares the full article, even if the layout isn't going to show it. The view just doesn't (and shouldn't) know if the layout will use it or not.

avatar nonumber
nonumber - comment - 4 Aug 2015

So probably better to not have the list and blog layout use the same view.
Here's a good example of where MVC is being counter-productive.

avatar Bakual
Bakual - comment - 4 Aug 2015

Having the same view for both layouts is fine. They both use the same data (more or less).
The issue is more how the data is preprocessed in the view. Maybe, some of it would have been better done in the layout. But due to B/C that can't be changed as it would need updates in all layouts from templates.

avatar nonumber
nonumber - comment - 5 Aug 2015

PS: Sourcerer already has these checks baked in.
So @jarea1050 is probably not using an uptodate version.

Add a Comment

Login with GitHub to post a comment