Jump to content
thirty bees forum

Traumflug

Members
  • Posts

    1,665
  • Joined

  • Last visited

  • Days Won

    82

Posts posted by Traumflug

  1. 2nd An Nginx + apache server for a small store (1000 products) is viable

    For performance considerations, the number of page views counts a lot more than the number of products. If you're that keen on more performance, it'd be better to analyse the current state, first. There are plenty of tools, e.g. Firefox' built-in web developer toolbox, showing each file loaded and how long it takes. If you have shell access to the server, run 'top' for a while and watch how much it swaps. No/rare swapping -> RAM is sufficient.

    4th is it feasible to put the store in normal web sites?

    Yes. Apache, PHP, database is sufficient.

  2. Like this https://www.beautyandpleasure.co.uk/admin46336vcsa/index.php?controller=AdminLogin&token=f041618e6c8126e8bdeeb9924cf6c734&redirect=AdminDashboard

    Am I mistaken or are you asking for the login page ('controller=AdminLogin') ? I think the redirect thing is expected to be handled after calling the controller, not before it. If this link isn't handcrafted it might be a hint to a bug on the page generating this link.

  3. Confirmed to be broken. HTML looks like this: generic <link rel="icon" type="image/vnd.microsoft.icon" href="/www.reprap-diy.com/shop/img/favicon.ico?1493478356"> <link rel="shortcut icon" type="image/x-icon" href="/www.reprap-diy.com/shop/img/favicon.ico?1493478356"> where www.reprap-diy.com/shop is the shop_uri (domain is 'localhost'). Also four lines of HTML for favicons in various sizes.

    Looking into apache's log, favicon.ico gets requested and delivered, but apparently by a picture with this question mark instead of the expected one. A request for /www.reprap-diy.com/shop/img/favicon_144.png is answered with 404.

  4. A Git repo doesn't stop you from doing an upgrade. Just upgrade and commit all the changes.

    Before doing so I'd make a DB backup and commit this backup file to allow rolling back later. A git history isn't of much worth if you don't have a matching database.

    For myself I use a Git repo filled with distributed files. Like

    generic 1.0.0---B-----1.0.1---B-----1.0.2---B----... \ \ \ \ \ \--L''--L''--L''--L''--L'' <= life site \ \ ---L'---L'---L'---L'---L' \--L----L----L----L----L Where: 1.0.0, 1.0.1, 1.0.2, ... unmodified installations made from distribution ZIP, then upgraded for each release. B = database backup, backup file committed into the repo. L = local code changes

    For each release I create a new branch on the previous unmodified installation, upgrade, then make a copy of the branch with previous local changes and rebase that to the new release. Sometimes a straight rebase is too complex, then I cherry-pick commit by commit from the previous branch, adjusting them as needed.

    All this requires to understand a Git repo not as a backup tool or dump yard, but as a tool allowing to build code like with Lego bricks (one brick = one commit), allowing to copy and move commits as needed. Reading up on 'topic branches' and on how to rebase them is a good starter.

    P.S.: 1.0.2 isn't released, yet. I put it into the graph for illustration purposes.

  5. Other than wit PS 1.6, the theme is a separate module. Try something like this: sh $ cd themes/community-theme-default/ $ git status $ git add . $ git commit If you want to prepare for a pull request, you have to work of a personal clone, too, just like with the main repo.

    As we're on the topic: updating all submodules goes like this (from the main repo, takes something like a minute): sh git submodule update --init --remote --rebase

  6. Is this topic solved? Please mark it as solved then, @atolodas. It's behind these three dots to the right of 'reply' and 'quote'.

    P.S.: actually I was wrong about this three-dot hamburger menu. Marking topics as resolved is in 'Topic Tools', rightmost in the series of buttons at the bottom of the first post.

  7. If you wonder whether it's normal to have a couple of commits on top of the public ones: yes it is. My own development repo currently carries a stack of 69 commits on top of master. Most of them already provided as pull requests, but also simple ones like "turn on debug mode".

  8. These are not unexpected. They're generated by one (or more) of the automatic upgrade processes built into 30bz (and PS).

    Either do a git checkout . to reset them or create a commit with all of them.

    Adding them to .gitignore isn't a good idea, because the English versions of these files are tracked in the main repository. At least at this point in time.

  9. Just trying a provider won't reveal whether this provider looks into your data. But data is there and unencrypted, so he can. The same is true for any other provider, of course. Unless you rent/own a full server equipped with an encrypted filesystem and do server maintenance yourself.

×
×
  • Create New...