lesley

It will likely be just a 1.0.4 final release we are testing it pretty well and the rc releases are getting virtually no downloads and testing.

Here is the plan as it stands now. The migration from Magento to thirty bees, I am not sure what @DavidP is talking about. We did write some pages sometime last year when we partnered with cart2cart about migrating different platforms, https://thirtybees.com/migrate/ We just updated the content a little bit for formatting when we launched the new site. The updater does need a big rewrite, but unfortunately, we are going to try to hobble along our current updater for one more version, so that is really not a huge hold up. What we have left on our list for 1.0.4 is this: Changing the way mailchimp collects email addresses from new shops. Integrating Patreon in the back office. Finishing the ad server so we can create a module page that draws modules from the store. This is the first step in doing away with the modules feed in your shop and showing only what is installed in your shop on the main modules page. (this is not to be confused with showing you more recommended modules in your modules list). Fixing a few more bugs. Everytime we think we have everything fixed a new bug comes in. Its a hard position to be in where you have to tell people that we aren't going to fix your bug in this version. re crowdfunding and other things: The development of the crowdfunding will start after 1.0.4 is released, so it makes sense to announce it, vote on it, and try to get it funded before then. The crowdfunding is a way to both add value to the project as a whole and bring money into thirty bees. Last year, including the crowdfunding for elastic search, thirty bees made $3600. This is not enough to cover the services that we need to keep the project running muchless either of us being compensated for our time. I am spending more and more of my time associated with the project trying to bring in revenue. We currently have 10k shops running thirty bees and only 21 of those shops feel like our software is important enough for them to donate to, to help keep the project alive. This is why we are spending more time looking for ways to monetize thirty bees. I have personally decided to not take any money from thirty bees until @mdekker can have a monthly salary and all the bills are paid. Going this route will accelerate the core development and is what should be done. Maybe this is too much information, but we have always tried to be as open and honest with our community as we could, we believe in transparency.

Leave them and use the page to offer the new updated products.

Oh, thats not it then.

Hmm, I wonder if it had to do with out new GA module. You are in the EU aren't you?

Not that I know of.

Just use the htaccess editor in the back of your shop.

I have never seen them done like that before. this is how I have seen them done Redirect 301 /old-url/page.html https://site.com/new-url/page.html

There is not, redirects need to be done by hand.

Not that I am aware of. But if the page is ranking well anyways, then not much is lost by changing it. Just put in a 301 redirect and all the link juice will pass.

If it changes the final url, yes, it will affect SEO.

I cannot speak for this module or company because I have not contacted them or used them, but I did see that they supported both banggod and thirty bees, https://mydataprovider.com/wholesalers-list It might be something that works for you.

I have had a few people use shipstation, they seem to like it.

Its not that it is not important, its that we need to come up with a solution that includes as many use cases as possible.

Returns are a rarer event in the US and the non EU world, since the buyer pays shipping both ways.

I think they cancel the order and remake it.

These things are where the complexity comes in tbh. Most shops do collect money on order, so things like that have to be taken into account.

I have a question with a case in point. Say I have a shop that sells widgets and I take payment with paypal and stripe. Then I have two shipping methods, free and express. If a user calls and wants to change to express, but it increases the order total by $10, what do I do?

No, I take that back, it looks like we might be affected.

We use a later version of smarty that does not have that exploit. We use 3.1.19

I have been wondering where I can add all the blog posts I have done about different speed related things. There are quite a few on our blog that break some of these things down, but not one central article. These are some of the better ones https://thirtybees.com/blog/the-problems-with-speed-optimization-tools/ https://thirtybees.com/blog/pagespeed-is-dead/

In the core we return a ps_version to make prestashop modules work with thirty bees.

Yes, we have already discussed different ways to accomplish this internally, it will likely be a feature in 1.1.x.

I would vote to just remove it... do people actually use them these days?

It is something we improve with every release actually. Its a very difficult process to be honest to compare multiple sites with multiple test metrics, but its something I will try to tackle. The first test you posted, when clicking on the link, this is what I see (I am screenshoting because they vary over time). thirty bees, http://storage6.static.itmages.com/i/18/0123/h15166741159059172af10a6ed5d.png PrestaShop 1.7 http://storage8.static.itmages.com/i/18/0123/h151667417027097160682054075.png I would be lying if I said we beat them, because we clearly arent. But why aren't we? That is the better question to ask. In a round about way, it is because we care about data security, we care about SEO. To be point blank, it is because we use an SSL certificate and secure the site. Notice that PrestaShop's demo is non https. Also look in the screen shots I posted and the links you posted. SSL negotiation is taking around 500ms. If we wanted to put out a demo that was pure speed without best practices, we could. Here is what our demo does with SSL turned off. http://storage2.static.itmages.com/i/18/0123/h15166744117583843_ddcee009c6.png We beat them in that case. TTFB is a meaningless metric in my opinion. Like I wrote about in a post last week, what is better a .2 second ttfb and a total page load of 4 seconds? Or a .5ttfb and a full page load of 2 seconds? Are users going to notice the 2. seconds or the 2 seconds? I err on the side of the 2 seconds. I prefer the raw speed approach. If you look at this test https://tools.pingdom.com/#!/dTflqp/http://fo.demo.prestashop.com/en/ https://tools.pingdom.com/#!/d31zoF/http://front.thirtybees.com/ Which loading time would you prefer? Then scroll down and look at the ttfb. We lose that. Which is more preferable though, a site that loads in .6 seconds or 2 seconds? In the future its going to get even more complicated that this. Lighthouse is replacing PageSpeed as the preferred metric, its metrics are more meaningful than PageSpeed, it is more of a real world metric. It takes into account not only the loading time of a site, but the processing time as well. I am sure you are like me, you have loaded a site on your phone, it comes up with a blank screen and the bar is spinning. Does that mean the site is still download? It does not actually, your smaller phone processor could actually just be parsing everything that was download. This is where Lighthouse comes in. It does not just grade on TTFB or complete download of files. It rates off how quick a user can see the first paint of your site and how quickly a user can start using your site. These are more real world and meaningful. From my tests just now. http://storage3.static.itmages.com/i/18/0123/h15166758288703700ddcee009c6.png http://storage4.static.itmages.com/i/18/0123/h151667588366811283dfd302eaf.png This is something else we win hands down in. In the future it will only get better after we move away from the 1.6 themeing style and more to our own.