Jump to content

ecartz

♥Ambassador
  • Content count

    3,604
  • Joined

  • Last visited

  • Days Won

    61

Posts posted by ecartz


  1. If someone deliberately locked the App, then Harald shouldn't change the status unless asked by the original developer.  The whole purpose of locked Apps is so that someone can have a place where only their uploads are. 

    Just create a new App.  The new App can be unlocked if you want. 

    Reading back, there are more than just two changes to get it working since the last release.  A bunch of TABLE_CONFIGURATION to replace. 


  2. 3 minutes ago, SuperPower09 said:

    it appears the user is able to bypass the landing page

    Well, yes.  In general, users are able to bypass landing pages by going directly to the URL.  If you don't want that to happen, then you need to build something in the cart itself that detects if a login occurred yet.  E.g. a hook that runs on every page but login and create_account.  You can't simply rely on the ceid's existence for that.  That's not what it does. 

    I mean, either set a cookie (not the ceid) on the landing page and check for that or require the sign up in the cart and require login on all pages except login and create_account. 

    It would be possible to block creation of the session if a cookie did not exist.  But it would be a lot easier to simply redirect, session or no session, if the cookie does not exist. 


  3. The ceid won't show up until you visit a page in the osC install.  So if your landing page does not include includes/application_top.php, it won't start the session nor add the session ID to URLs/cookies.  So it may just work.  For example, if the landing page is a pure HTML page. 

    If your landing page needs to include includes/application_top.php from the osC install, then I think that we need more about what you are trying to do.  Please explain the flow.  E.g. a possible flow would be

    1.  Pure HTML landing page or a PHP landing page that does not include includes/application_top.php.

    2.  Link to the osC create_account.php page. 

    3.  Submit normally. 

    The ceid would show on steps 2 and 3 but not on step 1.  This is an example flow that would just work.  It's possible that it might start a different session if you use a PHP landing page -- I don't do much PHP outside osC and forget how automatic that is.  If you use a pure HTML landing page, it definitely won't start a PHP session. 

    You may or may not want to explain more about what the landing page does as well.  Because I'm having trouble following the purpose. 


  4. If you want to try something before Rainer has a chance to look at it, consider changing

     if ($this->enabled == true) {

    to

     if ($this->enabled && !defined('DIR_FS_ADMIN')) {

    or

     if ($this->enabled && isset($_SESSION['cart'])) {

    Either of those should fix installing.  So at least you could test more interesting things.  Of  course, there's some risk that this will break something else.  So you could wait for Rainer to look into it. 


  5. 8 hours ago, douglaswalker said:

    Use of undefined constant CHARSET - assumed 'CHARSET' (this will throw an Error in a future version of PHP) in /home/woodtoys/public_html/includes/classes/seo.class.php on line 1831

    Note that CHARSET is still in the latest Phoenix:  https://github.com/gburton/CE-Phoenix/blob/master/includes/languages/english.php#L34

    It's almost certainly also present in the default Frozen.  Perhaps you edited it out but need to put it back? 


  6. 51 minutes ago, 14steve14 said:

    Fatal error: Uncaught Error: Call to undefined function tep_navbar_store_search()

    This suggests that there is something missing from your App install.  As that isn't a core function.  And includes/modules/content/header/cm_header_store_search.php isn't a core file.  Note that tep_navbar_store_search is in that file.  So presumably you broke something in one of your edits to that file.  This isn't something that could be broken by folder structure changes, as it is in the same file. 


  7. 1 hour ago, SolidAmerica said:

    Warning: Cannot modify header information - headers already sent by (output started at /home/www/mysellingstoreexample.com/.com/stores/includes/system/versioned/1.0.5.1/customer.php:62) in /home/www/mysellingstoreexample.com/.com/stores/includes/functions/general.php on line 36

    This says that you have display_errors turned on.  You can add

    ini_set('display_errors', '0');

    to includes/configure.php to turn it off.  Or turn it off in your hosting account if they allow you to do that. 

    You should not have display_errors turned on in your live store. 

    The warning and notices will be fixed in the 1.0.7.8 release. 


  8. 19 minutes ago, marokech said:

    while keeping the same USU5 module (language class removed in 1.0.7.3)

    The language class may have been moved, but it is unlikely it was removed.  If that were the one and only problem, it could presumably be fixed if you explained what the actual problem was. 

    If it's that there is code that you used to add immediately after the language code, then you can just move it into the i() function.  Change

         if ( !self::$_singleton instanceof Usu_Main ) {
           self::$_singleton = new self;
         }

    to

         if ( !self::$_singleton instanceof Usu_Main ) {
           self::$_singleton = new self();
           global $lng;
           self::$_singleton->setVar( 'languages_id', $_SESSION['languages_id'] )
                   ->setVar( 'request_type', $GLOBALS['request_type'] ) 
                   ->setVar( 'session_started', $GLOBALS['session_started'] ) 
                   ->setVar( 'sid', $GLOBALS['SID'] ) 
                   ->setVar( 'language', $_SESSION['language'] )
                   ->setVar( 'filename', $GLOBALS['PHP_SELF'] )
                   ->initiate( ( isset( $lng ) && ( $lng instanceof language ) ) ? $lng : [], $_SESSION['languages_id'], $_SESSION['language'] );
         }

    And you can add the other change to includes/classes/application.php -- find

          $_SESSION['navigation']->add_current_page();

    and add after it

      if (USU5_MULTI_LANGUAGE_SEO_SUPPORT == 'true') {
        include_once 'includes/modules/ultimate_seo_urls5/includes/hreflang.php';
        global $lng;
        $GLOBALS['usu5_multi'] = new FWR_hreflang( $_SESSION['navigation'],  $_SESSION['language'],  (isset( $lng ) && ( $lng instanceof language ) ) ? $lng : [], $GLOBALS['session_started'] );
      }

    That's not the ideal solution, but it should get you around your immediate problem. 

    A better solution would rename the file and/or class so that the autoloader would load it (no more include_once).  And create a no-arg factory method for it that could be called from a hook.  Then you wouldn't need to make a core edit.  But if the only thing keeping you from using this App is that you can't find the code to edit in application_top.php, there it is.  Presumably something like this is part of what piernas needs to test. 


  9. 10 minutes ago, SolidAmerica said:

    Warning: Cannot modify header information - headers already sent by (output started at /home/www/mysite.com/stores/includes/system/versioned/1.0.7.3/payment.php:65) in /home/www/mysite.com/stores/includes/functions/general.php on line 36

    To fix this, turn off display_errors in the PHP configuration.  Then the notices will not be displayed on the screen and won't break redirects. 

    I do not know why you are getting these notices though.  It seems to be saying that no payment module has been selected. 

     


  10. That sounds like you are using a very old version of PHP.  5.3 maybe?  If you can't update PHP, perhaps try an older version of Stripe SCA. 

    You could try replacing the [ on that line with array( and the ] with ).  Not sure how many times you'd have to do that in the file though. 


  11. There is a forum for PayPal questions:  https://forums.oscommerce.com/forum/54-paypal/

    There are several recent topics that say that PayPal made a change that requires an updated certificate.  If you made no coding changes and it just stopped working, that seems the most likely explanation.  The up-to-date version is at https://github.com/gburton/CE-Phoenix/blob/master/ext/modules/payment/paypal/paypal.com.crt

    If that is not it, it is barely possible that your host updated PHP in a way that broke your site.  But the certificate is both more likely and an easier fix, so I would check that before talking to your host. 


  12. 4 hours ago, mendoh said:

    Save this email.php file in a directory named includes/system/override (which you will probably have to create) and see if it starts working.

    OK.  But what actual error was that file causing?  It's possible that someone might be able to help you with that. 

    Note that while Stewart has not gotten it working by following those instructions, he has gotten it working by jamming the contents of the file in a different location.  It does still require installing PHPMailer and configuring it.  I know nothing about configuring PHPMailer, so I can't give you any guidance with that.  But still, someone else might be able to do so.  For example, Stewart did apparently get that part of it working. 

    4 hours ago, mendoh said:

    How can any customer registering on the shop with a hotmail or gmail address get an email confirmation for their order if non-SMTP authenticated emails get blocked before being delivered to hotmail/gmail addresses?

    This seems more like a hosting problem.  I have certainly sent emails to my gmail address through a sendmail executable.  If your host doesn't support that, I would recommend switching hosts to one that does.  Note that talking about non-SMTP emails is simply nonsense.  All emails are SMTP.  The difference is the three kinds of access to SMTP.  The sendmail kind is a local executable on the PHP server.  The "SMTP" kind is a local SMTP server on the PHP server (primarily for Windows).  The authenticated kind is a remote SMTP server.  So what your host is saying is that rather than handling the authentication for you, they want you to authenticate manually.  Because that's less work for them.  I'd suggest saving them even more work and switching to a different host.  Note that two of the certified developers are associated with hosting services. 

    Eventually, I'm sure that someone is going to have to spend resources to get authenticated SMTP working.  There seems to be a hope that "someone" will be either me or Burt.  But even if it was, then I can tell you, that it would be released as a supporters' code rather than in core.  So it might be better to approach one of the certified developers about it.  As they are more likely to simply update the existing authenticated SMTP App with PHPMailer to work with Phoenix.  It shouldn't even be that difficult, as I already rewrote and posted the code to do it.  So what's left is essentially writing the instructions for installing and configuring PHPMailer and bundling the files properly. 

    Rainer supports a large number of legacy Apps that are no longer supported by their writers.  John has experience with custom email configuration.  Preston likes to write Javascript package installers.  It's possible that any or all of them might be interested in that kind of project. 

    Another alternative would be filing a feature request with PHP.  There is of course no reason why they couldn't implement authenticated SMTP in PHP itself.  Then you would just have to configure it properly and you'd be able to use the mail function normally with a remote SMTP server.  That would fix not just this software but PHP software in general. 

×