Jump to content

MaXi32

Members
  • Posts

    98
  • Joined

  • Last visited

Everything posted by MaXi32

  1. Are you using the latest Prestashop version and module?. I tried linking and it was fixed for both Prestashop Facebook and Prestashop Metrics. They said this is related to the Prestashop native module called ps_accounts. Will test again for another site.
  2. Sorry for bumping the old thread but I actually understand what the OP want. He only want to avoid any technologies detect that he is using Prestashop framework. What he asking for is similar to a plugin called hide-my-wp for wordpress (and that plugin is considered as a security plugin, yes hiding your platform from public is considered one of the security approaches .. so he is asking a security question which he did not specify more) but I don't think this plugin exist for Prestashop as Prestashop code is harder to understand compared to wordpress. Hopefully there is one available.
  3. Hey @JulienPct, I really appreciate your reply on this. Thank you very much. Now, I learned something new that the folders above will not get replaced when the new version get released (perhaps through 1-click update?). This is something that I hardly find in the documentation. But then I think, I have the reason why I should version everything because if something goes wrong with the site, (let say the backup restoration failed). I can use this git idea to restore my site. I can create an empty server then pull the git files into my servers and finally just replace whatever sensitive files that I did not include before. The reinstallation thing is the reason why I don't want to experience when the site get deployed unless it is easy to migrate the database... So, my plan was to version everything including dumping the database. I have a ready bash script that when I trigger a command it will dump the database and automatically use git command to commit my repo. So I got database + files version in one command. The only thing that I care is, since I place this files in private repo in github (as a backup), I should make sure that I ignore the sensitive files... as to prevent those GitHub employees spy on the authentication files just for fun. Seems like from your list, you did not exclude sensitive files like password. If I use git only for local development I don't care about sensitive files but the reason is I also want to 'PUSH' it to private server. That's why I need to exclude sensitive files.
  4. Hello guys, just a quick question that I could not find it mention anywhere about building my .gitignore for sensitive data for Prestashop 1.7.8.1. I want to create a git repository for my current Prestashop and I only want to exclude sensitive information from the .gitignore like username, password or any PHP session files plus the /var/cache folder. For the rest, I want to include it if they do not contain sensitive data. This is my current .gitignore that I think they contain sensitive information and cache that should be ignored to be pushed to git repository: /.htaccess /app/config/parameters.yml /app/config/parameters.php /var Is there any extra information that should be excluded in this list for example the session files .
  5. Same issue here ... Prestashop module has a lot of bug. The only thing you can do is use alternative.
  6. Hai, great plugin, I purchased your module in envanto, and you deleted the item (I'm not sure why) but the issue here is that the license key that I purchased is not valid anymore. Why you are making the old license invalid?
  7. Since we are discussing about Prestashop Metrics, I do have question. In the latest version of Prestashop Metrics, it does however support linking with Google Analytic. However, it stated in the notification saying this: It said that it only support Google Analytics up to version 3 if using Google Analytic module developed by Prestashop. But for version 4 it is a paid module. When I click on Google Analytics module link above, it automatically install Google Analytics version 4. This is kinda bug here regarding to this notification. Perhaps the version 4 is working fine now? The reason I say this because Prestashop automatically install GA version 4 not the version 3. Anyone have thought about this? EDIT: It's ok, I misunderstood the previous notification. It did not say that the module is version 4 but it said the module only support version 3 and under. So, the module is working fine but it does not support GA 4 tracking code.
  8. My bad because I did not know what Matomo was, I thought you were referring to a module that use internal database as stats. I'm not a big fan of Google (and I agree Google is not a good product when it comes to privacy). From what you are saying above, I think any external scripts or fonts can slow down your site if network issue happens. So, it is not just a Google issue. What my previous point mean is, you should never rely on the Prestashop stats that will fill up your database day by day, unless that you have a dedicated database for your Prestashop. So, you should rely on external tracking script such as Google Analytic or Matomo (as mentioned by @JBW ). Using external tracking analytic can increase site performance. There is a nice blog talking about performance impact here if you use Prestashop stats and they recommend using external tracking: https://canonicalized.com/prestashop-speed-optimization/?section=prestashop-performance-options .
  9. I don't agree with this .. if you dont want to slow down your site using built-in states, then Google Tracking is the way to go.
  10. Update: Support has fixed this issue and informed me in the ticket.
  11. I just want to inform that this bug I mentioned is actually related to this:
  12. The issue has not been fixed. I have sent ticket to support 3 days ago and got no response until now. They said they are aware of this issue. I think this solution kind of effective. To summarize what you are talking here, this is similar like don't let prestashop use www make the domain as non-www. I'll try this now. SOLVED: EDIT: Guys the issue is solved following the above workaround. This definitely a bug at Prestashop server where it could not determine your root domain to link to your shop. So it does not work if you put subdomain like www into it. Thanks to @Jay Jay for the workaround. Look at this post to resolve this issue if you don't want to mess your server configuration: https://www.codegix.com/resolving-error-shops-0-your-shop-is-already-linked-and-verified-in-prestashop/
  13. Yeah that is what I did before your post. I knew that they are not gonna replied here but I just leave this here in case someone (the normal user) who does not know where to go. This is the bug reported: https://github.com/PrestaShop/PrestaShop/issues/26595
  14. EDIT 2 (add screenshot). This is the screenshot of the final error. Why does it complain about Error getting domain? More info: My shop is not in maintenance mode Prestashop version 1.7.8.0 PHP version: 7.4 Webserver: nginx_apache Installation type: New Can any prestashop team look at this issue because I believe the error came from prestashop server and this error is not documented anywhere
  15. It's been a while that I haven't used the latest version of prestashop. Now more things have changed and this is a new feature for me that I could not passed this website association using prestashop metric: A very simple step to reproduce this issue is: 1) Go to dashboard open PrestaShop Metrics 2) Now I clicked the Associate button 3) I login using successfully using credential that I had before 4) The website field www.domain.com is inserted (my shop domain). Now I clicked on accept and associate but then it said: Error! Your shop could not be associated with your PrestaShop account 5) Clicking problem details it said: ["shops.0.Your shop is already linked and verified"] 6) Well now I go ahead thinking maybe I should disassociate the website first. So I clicked on View my associated shops and click Dissociate and it asked the following message with two button Are you sure you want to remove this shop from your account ? If you have ongoing subscriptions, it will be impossible to cancel them. [Cancel] [Dissociate] 7) Of course I clicked on Dissociate and now the final issue is I got the following error: Error message We were unable to contact your shop, please contact support. "Error while getting domain" And I repeated this step many times and I could not use this feature. Anyone experiencing this issue?
  16. Sorry for late reply. It's been few months. I actually use Directadmin control panel. When you use nginx_apache, the prestashop site run on nginx and you can use apache config. So it works out of box.
  17. I use nginx_apache reverse proxy and it works great.
  18. Seems like an old threat but valid question as today so many cases like this one. Since you ask about how to block proxy sites or tor exit and you need this in free way, i suggest that you use a firewall that come with this feature such as Config Server Firewall (CSF)- This is free and it has blocklists setting where you can block tor exit users and list of proxies used by internet users to make this fraud transaction.
  19. Edit. Solved it. Actually it works on prestashop 1.7.6.8. Maybe something wrong with the previous prestashop version but now it's working fine when changing to date. Just change what I said. Also I made a mistake about the type. It should be 'date' not 'birthday'
  20. Ok I think the best is using htaccess for all website. So, I don't have to query SQL: This code is working fine here: web_user="admin" web_domain="mypswebsite.com" # web_sub_folder="" web_type="prestashop" admin_path="admin" maintenance_status=1 #1 = on, #0 = off # DEFINE FIXED PATH for all maintenance htaccess sites maintenance_htaccess_www="/home/$web_user/domains/$web_domain/public_html/$web_subfolder/.htaccess" # DEFINE ANOTHER PATH for htaccess maintenance file # for prestashop maintenance file ps_maintenance_htaccess_admin="/home/$web_user/domains/$web_domain/public_html/$web_subfolder/$admin_path/.htaccess" if [ $maintenance_status == 1 ]; then echo "[$script_name | info]: Turning on server maintenance mode for user $web_user" | tee -a $REPORT_FILE # rename current htaccess as backup .htaccess_x mv -f "${maintenance_htaccess_www}" "${maintenance_htaccess_www}_x" # create .htaccess file with maintenance content including the html (overwrite) touch $maintenance_file_www echo "# AUTO GENERATED BY MAXIRSYNC BACKUP CRON" >> $maintenance_htaccess_www echo "# This htaccess putting website $web_domain into maintenance mode" >> $maintenance_htaccess_www echo "RewriteEngine on" >> $maintenance_htaccess_www echo "RewriteCond %{REQUEST_URI} !/maintenance.html$ [NC]" >> $maintenance_htaccess_www echo "RewriteRule .* /maintenance.html [R=302,L]" >> $maintenance_htaccess_www # wait 1 seconnd chmod 644 $maintenance_htaccess_www chown $web_user:$web_user sleep 1 if [ "$web_type" == "prestashop" ]; then # DO PRESTASHOP THING # rename current htccess inside admin_dash into .htaccess_y mv -f "${ps_maintenance_htaccess_admin}" "${ps_maintenance_htaccess_admin}_y" # copy the same .htaccess including permission file from root to admin_dash cp -p "${maintenance_file_www}" "${ps_maintenance_htaccess_admin}" elif [ "$web_type" == "wordpress" ]; then # DO EXTRA WORDPRESS THING : fi echo "[$script_name | info]: OK, the website of $web_domain is now under maintenance mode" | tee -a $REPORT_FILE else # maintenance status = 0 # rename the backup .htaccess_x into .htaccess (and overwrite) mv -f "${maintenance_htaccess_www}_x" "${maintenance_htaccess_www}" if [ "$web_type" == "prestashop" ]; then # PS # rename back the admin_path .htaccess_y into .htaccess inside that admin_dash folder (and overwrite) mv -f "${ps_maintenance_htaccess_admin}_y" "${ps_maintenance_htaccess_admin}" elif [ "$web_type" == "wordpress" ]; then # WP : fi echo "[$script_name | info]: OK, the website of $web_domain is now under live mode" | tee -a $REPORT_FILE fi
  21. I'm writing the script to put all website in maintenance mode. The bash script is dynamic so it will identify which user to put into maintenace mode, using sql statement is not good here to identify which web_user. So if there is a way like using file based maintenance mode (like wordpress) I really like to know this: #web_user="userwordpress" #web_domain="mywsite.com" #web_sub_folder="www" #web_type="wordpress" #maintenance_status=1 #1 = on, #0 = off web_user="userprestashop" web_domain="mypssite.com" web_sub_folder="www" web_type="prestashop" maintenance_status=1 #1 = on, #0 = off if [ $maintenance_status == 1 ]; then if [ "$web_type" == "wordpress" ]; then echo "[$script_name | info]: Turning on server maintenance mode for user $web_user" | tee -a $REPORT_FILE maintenance_file="/home/$web_user/domains/$web_domain/public_html/$web_sub_folder/.maintenance" if [ -f $maintenance_file ]; then echo "[$script_name | info]: OK, the website of $web_domain is already in a maintenance mode" | tee -a $REPORT_FILE else touch $maintenance_file echo "# AUTO GENERATED BY MAXIRSYNC BACKUP CRON" >> $maintenance_file echo "<?php" >> $maintenance_file echo "$upgrading = time();" >> $maintenance_file echo "?>" >> $maintenance_file chmod 644 $maintenance_file chown $web_user:$web_user echo "[$script_name | info]: OK, the website of $web_domain is now under maintenance mode" | tee -a $REPORT_FILE fi fi if [ "$web_type" == "prestashop" ]; then # Prestashop put maintenance mode fi else # maintenance status = 0 if [ "$web_type" == "wordpress" ]; then if [ -f $maintenance_file ]; then rm -f $maintenance_file fi else # Prestashop put back live mode fi fi
  22. Ok that is a great idea. But, I forgot to mention, I don't want to write script using sql like above because it has sensitive information about db login. I mean is there alternative way other than changing the database table ? If no way I think setting the employee table as inactive is the best idea.
  23. Hello there, what are the alternative ways to put prestashop into a maintenance from the backend server ? At this moment, if I want to manually put a prestashop website into maintenance mode, I can manually change the ps_configuration table. So, I created a bash script and change the database table to maintenance mode like this. This is working for me: echo "[$script_name | info]: Turning on server maintenance mode for user admin:" | tee -a $REPORT_FILE # For lozira.com (prestashop) LOZDBUSER="dbuser" LOZDBPASS="dbpass" LOZDBNAME="dbname" # Clear Prestashop IPs from back office mysql -u $LOZDBUSER -p$LOZDBPASS -D $LOZDBNAME -e "UPDATE ps_configuration SET value = NULL WHERE ps_configuration.id_configuration = 1002;" # Disable prestashop shop from back office mysql -u $LOZDBUSER -p$LOZDBPASS -D $LOZDBNAME -e "UPDATE ps_configuration SET value = 1 WHERE ps_configuration.id_configuration = 28;" return_code=$? if [ $? -eq 0 ]; then echo "[$script_name | info]: OK, the website of domain.com is now under maintenance mode" | tee -a $REPORT_FILE else echo "[$script_name | info]: Warning, unable to put website of domain.com in maintenance mode" | tee -a $REPORT_FILE fi The front page is under maintenace mode but I notice I can still access into the back office domain.com/backofficeurl (this is what I don't want). I also want to block admin users from accessing the back office until the script finished running. Another way I can think of is creating maintenance using .htaccess in the root domain and then another htaccess inside domain.com/backofficeurl.. but is that one of the alternative approaches ? How do you put the entire site including people at the back office who won't be able to log into dashboard ? Then you can enable this from the server. I know how to do this in wordpress using .maintenance file but in prestashop I don't find any alternative ways. Is there an approach like wordpress .maintenace file ?
  24. I guess the range of the ID has maximum of 2,147,483,647. That is 2 billions click to go. So, if somebody could reach that ID, it's the end of Prestashop life . ps: it's the same issue with prestashop 1.7.6.7
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More