Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 21:29

    nitriques on 3.0.x

    Redirect loggued in users to AP… Add documentation about unambig… Allow numeric values in schema … (compare)

  • Jan 29 2019 19:40
    timokleemann commented #2861
  • Jan 28 2019 10:50
    animaux commented #2574
  • Jan 25 2019 18:25
    nitriques commented #2865
  • Jan 25 2019 18:23
    wdebusschere closed #2865
  • Jan 25 2019 18:23
    wdebusschere commented #2865
  • Jan 25 2019 18:09
    nitriques commented #2865
  • Jan 25 2019 18:09
    nitriques commented #2865
  • Jan 25 2019 18:07

    nitriques on 3.0.x

    Avoid double insert (write) exe… (compare)

  • Jan 25 2019 18:07
    nitriques closed #2882
  • Jan 25 2019 18:06
    nitriques milestoned #2882
  • Jan 25 2019 18:06
    nitriques labeled #2882
  • Jan 25 2019 18:06
    nitriques assigned #2882
  • Jan 25 2019 18:06
    nitriques review_requested #2882
  • Jan 24 2019 22:06
    wdebusschere commented #2865
  • Jan 24 2019 21:58
    wdebusschere commented #2865
  • Jan 24 2019 21:10
    nitriques commented #2865
  • Jan 24 2019 20:33
    wdebusschere commented #2865
  • Jan 24 2019 20:33
    wdebusschere commented #2865
  • Jan 24 2019 17:57
    nitriques commented #2865
Sadie
@Sadie

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.]

alt text

Under System > Sitemap, I get "Symphony Warning: array_pad() expects parameter 1 to be array, string given."

alt text

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.

alt text

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.

Peter Skirenko
@petertron
@Sadie There is a new fork of Breadcrumb, https://github.com/petertron/breadcrumb .
Sadie
@Sadie

@petertron Thank you so much for the link. I looked for forks but didn't find yours. Breadcrumb issue now resolved.

For anyone following the saga, System > Sitemap now generates the same error under 5.6 and 7.3, the array_pad() exception.

Sadie
@Sadie

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.

alt text

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.

Brian Zerangue
@bzerangue
@Sadie - Regarding the Sitemap XML extension, @pixelninja maybe able to help since he created the extension. But, you might try this Patch that someone submitted in the content.xml.php file. First backup that file, and the write these changes to that file and see if that works. mblabs/sitemap_xml@123c2d1

@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">
Brian Zerangue
@bzerangue
@Sadie - if you want a Import/Export CSV extension that works with 2.7.10. I believe @animaux's fork of the extension works with 2.7.10. https://github.com/animaux/importcsv
Brian Zerangue
@bzerangue
@Sadie - 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
@Sadie - I hope that helps.
Sadie
@Sadie

@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.

Alexander Rutz
@animaux

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!

Sadie
@Sadie

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.

Alexander Rutz
@animaux
@Sadie I think this should still be true: http://www.getsymphony.com/discuss/issues/view/360/
I actually never did that … will have a look at my sites. *cough*
Hmm, the mentioned commit is this —> symphonycms/symphonycms@845c656
Alexander Rutz
@animaux
Just did a quick check with an xlst-error on 2.7.10, with php_value display_errors offthe error message is shown anyway, logged in or out.
This one says with 2.2 it should show the 404 page: http://www.getsymphony.com/discuss/thread/58752/#position-2 Tested that for 2.7.10, and it’s not working this way. Maybe it is different with php errors? Or is it because of the version?
Sadie
@Sadie

@animaux Don't feel bad...the developer of this site didn't implement anything either!

I can confirm the 404 page does NOT display for 500 errors for 2.6.1 either, as that is the live site I'll be replacing with the upgraded one, so that was a short-lived fix, if it ever was one.

Alexander Rutz
@animaux
Just checked with PHP errors, and it’s the same. php_value display_errors off doesn’t seem to have an effect. Normally the customers reported errors pretty fast so we were able to fix stuff :), but this really is a serious problem.
Sadie
@Sadie
I know, I was horrified to see all those file paths when I received the link to the site with the question, can you fix this?
Alexander Rutz
@animaux
@jonmifsud once sent me a set of special backend templates (not XSLT) that can be used to modify stuff like this, but I never used them. There should be some switch for these messages, and I’m really surprised if there isn’t.
Sadie
@Sadie

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.

Alexander Rutz
@animaux
I think the »blank white page« is some error that’s not even making it to the error page, or prevents it from even turning up.
Symphony Fatal Fatal Fatal Error
Sadie
@Sadie
Makes sense, I can't remember what the error was now. That was a really old post, 2014 I think, so maybe that was in the era of Symphony 2.2 you mentioned earlier.
Alexander Rutz
@animaux
I think there’s some discussion here: symphonycms/symphonycms#2509 but it’s way over my skills … and development of symphony has virtually stopped with 2.7.10/3.0.0, so no idea where else to look at the moment.
Alexander Rutz
@animaux
Looks like it boils down to that PR, that was not pulled. If I understand correctly, Nicolas redid the changes for 3.0.0, at least in my 2.7.10 version these lines do not exist: https://github.com/DeuxHuitHuit/symphonycms/blob/f783d41aab2e3d0edad6371305cc6e7b25a09632/symphony/lib/boot/bundle.php#L24-L26
Just tried adding those. The error pages gets smaller, but still reveals all the paths …
Sadie
@Sadie
@animaux That discussion is out of my league, too. OK, that which is added to 3.0.0 might be something to follow up on. Thanks for looking! I have to leave for a virtual meeting, will be away for a couple of hours. I'll keep you posted on anything I find.
Alexander Rutz
@animaux
3.0.0 breaks a lot of other stuff unfortunately. Will go to bed, it’s late in germany ;). Will also let you know it I get wiser. Maybe someone else can chime in.
There are 52 changed files in that PR … argh.
Alexander Rutz
@animaux
A nasty way of preventing error messages is to comment out the content of the render($e) {} function in /symphony/lib/core/class.errorhandler.php, starting on line 201. This renders a white page on error.
Only works for PHP-errors though …
Sadie
@Sadie
@animaux you mentioned @jonmifsud which was a name I'd run across in Google search results, but his site no longer exists. Thanks to the Wayback Machine I found the Jon Mifsud post that discusses custom error pages. I haven't tried to do this yet; it's been a long day. I'll be back on it tomorrow.
Juraj Kapsz
@jurajkapsz

Heh, wrote this in the wrong chatroom (Symphony Help), so just for record here again:

Guys, count me in when we should have a joint call of Symphony CMS community, I think such idea was mentioned recently. I should be available from april and onwards.

Alexander Rutz
@animaux
I have just finished a major new version of the 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
Alexander Rutz
@animaux
@jurajkapsz The main problem with »a joint call of Symphony CMS community« is that it would need coordination. Don’t know if @nitriques can be around? In my opinion the three most important things would be:
  1. commit critical bugfixes for 2.7.x (is LTS even an issue any more?) in the main repo
  2. commit critical bugfixes for 3.x in the main repo
  3. PHP8 fixes for 2.7.x and 3.x while retaining backwards compatibility with PHP7?
  4. include (more) active members as admins for the github symphonists account in order to check/approve PRs
Is anyone working productively with 3.x? I have not been able to use it at all.
Juraj Kapsz
@jurajkapsz
@animaux yes, if there should be a call, we could put together points we want to talk over. My points are similar if not the same. As of 3.x, I did not tried it yet, it's next on my todo list, I should get to it in about a month or so.
Juraj Kapsz
@jurajkapsz

I have just finished a major new version of the 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

@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.

Alexander Rutz
@animaux
@jurajkapsz I’m happy if it’s useful!
Nimantha Harshana Perera
@nimanthaharshana

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.

Wannes Debusschere
@wdebusschere
Screenshot 2021-03-08 at 13.55.41.jpg
Screenshot 2021-03-08 at 13.55.54.jpg
i tried to upload a test.php
Alexander Rutz
@animaux

if someone gets into the backend somehow

Hmm. It would have to be a dev-account this someone would need to have access to. With a compromised dev-account I can imagine all kinds of other bad things possible …

Can verify .php upload is blocked.
Bildschirmfoto 2021-03-09 um 11.11.54.png
Alexander Rutz
@animaux
I also tried a php file with no file-extension, that got blocked too.
cylkee
@cylkee
@nimanthaharshana Versions tested?