I've just installed SMF 2.1.4 via Softaculous. I've installed the theme ProCurve as it looked to be the easiest to edit so it would integrate with the site I'm creating.
I've been able to edit the index.css file successfully within the SMF interface to accommodate content to go within the <div id="header"> tag but I run into problems when I attempt to edit that part of the index.template.php file.
(Now I know this isn't necessarily the best way to do this but it serves to illustrate the problem I have.)
I plan to replace the search box with other content. As a first step I attempted to stop the search box from appearing by wrapping the code in comments tags.
/*
if ($context['allow_search'])
{
echo '
<form id="search_form" class="floatright" action="', $scripturl, '?action=search2" method="post" accept-charset="', $context['character_set'], '">
<input type="search" name="search" value="" placeholder="Search..."> ';
// Search within current topic?
if (!empty($context['current_topic']))
echo '
<input type="hidden" name="sd_topic" value="', $context['current_topic'], '">';
// If we're on a certain board, limit it to this board ;).
elseif (!empty($context['current_board']))
echo '
<input type="hidden" name="sd_brd" value="', $context['current_board'], '">';
echo '
<button type="submit" name="search2" class="button no-border-radius" value="search"><i class="fa-solid fa-magnifying-glass"></i></button>
<input type="hidden" name="advanced" value="0">
</form>';
}
*/
However, on clicking the SAVE button, I find the file is reduced to 0bytes and all that's left on screen is a message saying the main_above template can't be found.
I've copied back in the "missing" file and all is returned to normal. But I find any edit I try also produces a 0byte file.
I would have said that my PHP skills are minimal and it's probably me doing something wrong. However, I've just downloaded the index.template.php file, edited it locally and uploaded it and it works just as expected. The search box is gone. (It is designed to disappear on small screens but I need to replace it with something that will always appear.)
So my question is, is there a known bug in the "Edit Theme" screen, or am I likely to be doing something that's not intended?
Whoa, now that's a f@#king bug. Confirmed. ;D
Quote from: NorfolkGreg on June 13, 2023, 06:09:32 PMSo my question is, is there a known bug in the "Edit Theme" screen, or am I likely to be doing something that's not intended?
Using the admin centre for editing templates is, quite frankly, a very bad idea. I can hack templates for breakfast, and I would still never edit a template via the admin centre. The smart way to do it is the other way: download the template, edit it in a proper code editor, then upload the edited
copy (because you will be keeping an unedited backup, just in case you need it).
TBH, I would usually not even edit a CSS file via the admin centre. FTP + code editor is much better. ;)
Did not test this, but logged this since Sir Osis confirmed seeing the same behaviour.
#7769 (https://github.com/SimpleMachines/SMF2.1/issues/7769)
Quote from: Antechinus on June 13, 2023, 09:03:15 PMFTP + code editor is much better. ;)
also we get syntax highlighting then which makes code much less painful to work with.
In all honesty, my preferred solution here is to remove the editor entirely.
^ This.
Yep, I would agree that is the smart option. At the very least, remove the ability to edit any PHP or JS files.
You could argue that CSS edits via admin are safe enough, but even those should not really be necessary.
I have not yet been able to reproduce the problem. I made the same edits described in the original post above, and the changes were saved without issue.
2.1.4 core install. > Modify themes, open any template and save, file is wiped. Seems to only affect templates, doesn't bother index.php or css files.
Same in 2.1.3.
That's what I did. Every time, the file was saved successfully.
I believe you are seeing your files wiped when you do it. But clearly there is some missing information about the conditions required to create the issue.
OP had edited a template, I'm doing nothing to it, just load and save, and it's wsod, file is 0 bytes. Could it be a server issue?
Same result in custom theme.
As ever, we should start off with the basics:
- PHP version
- db type & version
- OS info
- hosted/local
- is mod_security active
- any theme? Or default?
I cannot reproduce as well.
SecRuleEngine was on, set it off, same result.
Version Information:
Forum version: SMF 2.1.4 (more detailed)
Current SMF version: SMF 2.1.4
GD version: 2.3.3
ImageMagick version: 7.1.0-62 Q16-HDRI x86_64 20885 https://imagemagick.org (Imagick 3.7.0)
MySQL engine: MariaDB
MySQL version: 10.6.12-MariaDB-cll-lve
SMF file based caching: 2.1.4
SQLite3 database based caching: 3.39.4
PHP: 8.0.28 (more detailed)
Server version: LiteSpeed
Hey, you're getting better! Answering 3 out of the 6 questions! That's an improvement! ;D
Quote from: Sir Osis of Liver on June 14, 2023, 10:10:42 PMSame result in custom theme.
Shared server (Crocweb).
Different server, same host, custom theme, same thing -
Version Information:
Forum version: SMF 2.1.3 (more detailed)
Current SMF version: SMF 2.1.4
GD version: 2.3.3
MySQL engine: MariaDB
MySQL version: 10.3.38-MariaDB-cll-lve
SMF file based caching: 2.1.3
SQLite3 database based caching: 3.39.4
PHP: 8.0.28 (more detailed)
Server version: LiteSpeed
Try making the following changes in Themes.php and see if the result changes.
function EditTheme()
{
global $context, $scripturl, $boarddir, $smcFunc, $txt;
function EditTheme()
{
global $context, $scripturl, $boarddir, $smcFunc, $txt, $sourcedir;
$_POST['entire_file'] = rtrim(strtr($_POST['entire_file'], array("\r" => '', ' ' => "\t")));
// Check for a parse error!
if (substr($_REQUEST['filename'], -13) == '.template.php' && is_writable($currentTheme['theme_dir']) && ini_get('display_errors'))
{
$fp = fopen($currentTheme['theme_dir'] . '/tmp_' . session_id() . '.php', 'w');
fwrite($fp, $_POST['entire_file']);
fclose($fp);
$_POST['entire_file'] = rtrim(strtr($_POST['entire_file'], array("\r" => '', ' ' => "\t")));
require_once($sourcedir . '/Subs-Admin.php');
// Check for a parse error!
if (substr($_REQUEST['filename'], -13) == '.template.php' && is_writable($currentTheme['theme_dir']) && ini_get('display_errors'))
{
safe_file_write($currentTheme['theme_dir'] . '/tmp_' . session_id() . '.php', $_POST['entire_file']);
if (!isset($error_file))
{
$fp = fopen($currentTheme['theme_dir'] . '/' . $_REQUEST['filename'], 'w');
fwrite($fp, $_POST['entire_file']);
fclose($fp);
if (!isset($error_file))
{
safe_file_write($currentTheme['theme_dir'] . '/' . $_REQUEST['filename'], $_POST['entire_file']);
Fixed. Why weren't you able to replicate it?
Quote from: Sir Osis of Liver on June 14, 2023, 11:02:54 PMFixed.
Excellent.
Quote from: Sir Osis of Liver on June 14, 2023, 11:02:54 PMWhy weren't you able to replicate it?
No idea. I still can't. But it was obvious that something was going wrong writing the files to disk. So I thought it would be worth trying out the very heavily bulletproofed safe_file_write() function that I wrote for SMF 2.1 to see if it would work better.
This fix has been submitted in #7773 (https://github.com/SimpleMachines/SMF2.1/pull/7773).
Nicely done.
I am opposed to removing the feature.... I have used it myself when having to make emergency edits from my phone, when I don't have access to the normal file manager, ftp or text editors...
Yes, that works for you, but I think in general the people most likely to use the theme editor are also the least likely to make backups (editor doesn't), and the least able to recover if they crash the forum with a bad edit. If the feature is retained, might be a good idea to have a recommendation/warning up top that better methods should be used if available, and that backups are a must before editing a file.
I have to agree with Sir Osis here. TBH I think that if this feature is going to be retained it really should:
a/ make an automatic backup of the file which is about to be edited, and
b/ provide a means for the admin to access the backup file and overwrite with it.
That's the only way of allowing editing of PHP templates without the risk of trashing the site. And it's tricky, because a parse error will crash the site, so you would need to build in a way of circumventing SMF admin to allow the overwrite.
Which really brings things back to FTP + code editor. I have crashed a site with a parse error before, and if you have a backup ready to rumble it's a few seconds to FTP it into place.