This is a continuation of my Feb 16, 2021 post.
I have successfully updated a clone of the site and its db from Symphony 2.6.1 to Symphony 2.7.10, and under PHP 5.6, I am able to view both the front- and back-ends of the updated site. All extensions have been updated to the extent possible.
Two issues noted on the backend under PHP 5.6:
Under System > Preferences, I get "Symphony Fatal Error: Could not find Email Gateway. If it was provided by an Extension, ensure that it is installed, and enabled." The default gateway is defined as sendmail in /manifest/config.php. [The cloned site is in a subfolder of the live site, so maybe a path issue, but I can't find it.]
Under System > Sitemap, I get "Symphony Warning: array_pad() expects parameter 1 to be array, string given."
Under PHP 7.3, I disabled the CKEditor and Import/Export CSV extensions, which seem incompatible wtih PHP7. I can log in and view the back-end, with the same issues described above, except that System > Sitemap generates a Breadcrumb error "Declaration of datasourceBreadcrumb::grab(&$param_pool) should be compatible with Datasource::grab(?array &$param_pool = NULL)" I get the identical Breadcrumb error when trying to view the front-end under PHP 7.3.
Of all these, the Breadcrumb issue seems the biggest stumbling block. The Breadcrumb extension was one of the few that had no updates. Unfortunately, it is integral to the site.
I appreciate anybody's thoughts and advice about any of these issues.
A continuation of my 2/19/21 post
The Breadcrumb error fixed (see 2/21/21 post), thanks to @petertron .
The email gateway error, as well as a bunch of Section errors, were caused by new extension files I had uploaded but not "checked in" (for everything but this project, I work in a team environment, so lock files prevent the team from overwriting each other.) Once I checked the files in, thus removing the lock files, the email gateway error and section errors disappeared.
I'm now down to one error, the Sitemap array_pad() error previously mentioned. I get the error under both PHP 5.6 and 7.3. There IS an odd notification for Sitemap under "Extensions". It seems to not know I am now on Version 2.7.10, image below. I appreciate any ideas you have about this error.
It's thanks to this community, your many past posts that continue to help those of us trying to keep sites afloat we didn't create, and @wdebusschere who advised me on an upgrade plan, that this upgrade is nearly complete. So thank you all.
@Sadie - the reason the extension shows requires Symphony 2.7 is there is a max version set in the extension.meta.xml file. Located here... https://github.com/pixelninja/sitemap_xml/blob/master/extension.meta.xml#L18
If you change the max from 2.7 to 2.7.x that error will go away.
<release version="2.6" date="2017-07-15" min="2.6" max="2.7.x">@bzerangue Everything you suggested helped - a LOT. Thank you!
Both of your suggestions regarding Sitemap XML fixed the issues.
Updating to the @animaux version of the ImportExport CSV extension fixed the PHP7 issues.
Updating to the @animaux version of the CKEditor extension caused a sql error.
But an earlier post I'd read (@Timurrrcheg Oct 10 2020) told me what to do.
Changed Line 153 in extension.driver.php
Symphony::Database()->fetch('SELECT * FROMtbl_ckeditor_presets');`
to
Symphony::Database()->fetch('SELECT * FROMtbl_ckeditor_presets;');
I believe the site is successfully migrated to 2.7.10 and to PHP 7x! Thanks again to all.
it also looks as if @animaux also did a CKEditor extension as well, it looks as if he has updated it to work with 2.7.10. Take a look. https://github.com/animaux/ckeditor
Wow, I totally didn’t remember I did that :D. Great to hear @Sadie was able to fix everything. I can see if I can fix that line 153 in my fork too!
One more question, I'm just not finding the answer. Maybe it's just common knowledge I don't have since neither PHP nor Symphony are my native languages. When the Symphony site I inherited started throwing errors because of the host's upgrade to PHP 7+, the Symphony error displayed to the public with the complete path to the files. (I replaced index.php with a "temporarily down" file to hide the paths.) I assumed that display-errors was set to "on" in php.ini. But it isn't, all the error settings look right for production; it seems Symphony overrides those settings(?)
What is the proper way to hide these "friendly" errors in Symphony? I see the 404 error page in the back-end, but nothing for the 500 code. Is there a setting somewhere within Symphony? Or do I just add custom error pages in .htaccess? Thanks for your feedback.
Me too, thought I must be missing it.
Thing is, I THINK (it's been DAYS ago) when I first upgraded to 2.7.10 that I got a blank white page, with no detail. On the old forum I found a post where @brendo suggested adding "ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(-1);"
to index.php so you could see the error. So I did add it and could see the details., but removed it after I fixed the error. Now it seems I can't go back.
maplocationfield that gets rid of all Google Maps and Geocoding and uses Openstreetmap/Nominatim instead. It can be used as a drop-in replacement for the former version. Only limitation is that location names in stored fields and datasource filters are not supported any more, only latlng. I’m happy if anyone is interested in testing: https://github.com/animaux/maplocationfield
- commit critical bugfixes for
2.7.x(is LTS even an issue any more?) in the main repo - commit critical bugfixes for
3.xin the main repo - PHP8 fixes for
2.7.xand3.xwhile retaining backwards compatibility with PHP7? - include (more) active members as admins for the github
symphonistsaccount in order to check/approve PRs
3.x? I have not been able to use it at all.
I have just finished a major new version of the
maplocationfieldthat gets rid of all Google Maps and Geocoding and uses Openstreetmap/Nominatim instead. It can be used as a drop-in replacement for the former version. Only limitation is that location names in stored fields and datasource filters are not supported any more, only latlng. I’m happy if anyone is interested in testing: https://github.com/animaux/maplocationfield
@animaux nice, actually my current project uses maps services (Google), and I was also looking at this extension for backend use but went without it, though the extension was working fine. Anyway, the idea of Openstreetmap/Nominatim is very interesting.
Hi Everyone,
Hope all of you guys doing well. We are trying to secure our very few Symphony apps until they are migrated to new platform and we ran some security tests against those recently and found that if someone gets into the backend somehow they of course can take control over the server via following steps.
1) Create a new section with a file upload input without any restrictions
2) Upload an htaccess file by letting it run phpcode via a different extension
3) Run malicious php code and gain control over important assets on the server (Possibly the whole server via other possible attacks)
For the above particular issue we got an advice from the security team so that there should be a global file extensions whitelist (Not a blacklist) so that it's not possible to upload files such as .htaccess, .sh, .js etc... Restricting certain file extensions to the file upload input (in a specific section) is not an option here as we are talking about someone who already got into the backend. So only way to avoid this is to have a global level file extension whitelist so uploading any files other than in the whitelist is prohibited. We couldn't find a way to do this in the Apache config level and we think the only possibility would be to have a global level extension that will be in effect on file upload inputs.
Please can you guys share your thoughts on this ? WE STRONGLY BELIEVE THIS RISK COULD BE THERE FOR ALMOST ALL THE SYMPHONY SITES.
PLEASE NOTE THAT WE ARE NOT ALLOWED TO SHARE MORE INFORMATION OTHER THAN THE ABOVE STEPS.
