So apparently someone decided to build a Linux distro (boy, how many do we need of those, huh?), but this one isn’t based off of Debian, Ubuntu, Cent, etc… Nope, this one is based off of OpenSUSE, and its dubbed CalamariOS: http://ostatic.com/blog/calamarios-huh-what
I wasn’t exactly a fan of OpenSUSE before (it hated my dual-monitor set up), so I haven’t even tried it in the past year. But, I feel this can open a larger market to distros. It does get tiring seeing “hey, we just built a new distro based on Debian/Ubuntu and want you to try it!” So, I applaud this as a wonderful move forward in functionality. OpenSUSE never has really held much ground, however, which makes me sad for this project. But, who knows…this could be the steam needed to get SUSE up and going.
The two major turn offs for me on this, though, are Gnome and it comes preloaded. I’ve been using Arch for a few years now, and love the fact I get an almost barebones OS. Though, Arch is starting to go the way of the others too (I don’t need reiserprogs when I’m using ext4…just saying).
Time will tell on if this is going to be another dead project, but its definitely something to keep an eye on.
I remember back in the late 1990′s and early 2000′s, phpMyAdmin was the go-to way to manage a MySQL database. Even to this day a lot of people swear by it (and at it). But, especially if you’re working in a mixed environment that runs MySQL and PostgreSQL, for example, a single solution is better than running two different set ups.
My personal choice, even for MySQL now, is Adminer: http://www.adminer.org/
Its really a nice piece of software. A single PHP file, easy to theme, and connects to multiple database types. Granted, I mostly use it for Postgre, but its also a viable solution for MySQL and SQLite as well.
The interface is also pretty easy to work with as well. Its got a similar feel to phpMyAdmin, but its not as overly featured. It does what its intended to do (manage databases) without throwing in all these options to manage the server itself. Which, if you’re a DBA, you may or may not enjoy, but for a developer its more bloated than anything.
If you’re looking for a way to actually manage your database without managing the server, Adminer is about the best solution you can ever find.
SKYnet has been here for a while, but now we’re looking at SKYnet v2. Terminator edition.
No, I don’t want my car to update my Facebook status to let people know where I am. It’s already a horrible stalker medium as is. No, I don’t want to listen to what my friends are. Also, who thought it’d be a good idea to present information on a HUD (heads-up display)? This isn’t a first person shooter, this is driving. How is it safe?!
I’m sorry but long story short, I see no good coming from this. Its awesome on what they’re doing and how Ford+Facebook+Google are working together…but, I don’t see how it benefits the driver. How does it benefit me to have someone make an app to tell me when to get gas? I can look at the gauge and figure that out on my own. If the gauge is broken, wouldn’t the app be broke as well? Fix what we have now and worry about making a new shiny toy later.
I feel in this category, PrestaShop really shines. Its basically like a real store inventory system, and its amazing. With the power of Ajax, it gives you so many options without throwing it in your face at once. They’re separated by tabs on the left side, which makes it easy as pie to go to a specific part of the product and manage it.
In short there’s a lot of features that I won’t cover here, but is definitely worth looking into. You can specify if the item is online only, pre-tax price, what the tax is, etc… Can add more images, different properties/information, reference IDs (i.e.: SKUs). It will also keep track of your inventory, so if you want to make your job easier and run both a physical and online store, you can easily pull information from the database (the API is easy for this).
Overall, in terms of actually running a store, its pretty nice. Its like back in the day when you knew how much everything was and where everything was placed, you could price it off the top of your head. If this area was bad too, then I’d suck it up and go with Magento, but this is basically the saving grace for me for Presta.
One thing I’d like to cover though is that Presta does integrate with eBay. However, it only supports the France and German versions of the site. The eBay API isn’t horrible to work with (similar to PayPal’s if you have ever used that), but while there’s a huge demand for a UK and US support, the Presta team seems very hesitant on doing so. This could be due to the fact that Presta is based out in the EU nation set, but how that affects eBay’s services to them I don’t know.
As I mentioned before, the template system is based on Smarty. I’m not well-versed in how Smarty works or anything, but I can say this: Presta has turned me off from it.
PHP itself is an annoying language at its core. There are so many restrictions and fallacies it has that its almost not even worth it with the improvements of both Ruby and Python. Its like the HTML of scripting/server side languages.
The problem with the Smarty template system, though, is that Presta requires it to be compiled to improve speed. Which would be great, but if you don’t enable “force compilation”, you’re going to run into a lot of messes then. But, it seems even in doing so, I’m still having issues.
I went to install a theme, which went fine. However, the theme didn’t look anything like the demo did, so I decided to switch it back to the original for now. In doing so, the original theme became just as bad, if not worse. Everything was out of order, moved around, etc…
I can understand the compiling part of Smarty, since Presta is used a lot and I’m sure a good collection of heavily-viewed online stores use it. However, I don’t feel it was implemented in a proper way. It feels…forced?
At this point, I don’t even know what I can do to fix it now. Or if I should just delete the whole thing and start fresh. Which I might do the latter (kind of out of boredom and frustration). The install was fine, just seems like everything else is going down the tube.
I couldn’t wait to write this section. The API is both a blessing and a damn curse rolled into one.
First thing, the API works by parsing XML both in and out. So, you poll the API service to retrieve a XML structure of data that you then manipulate and send back. Not a horrible idea, in theory.
I’ve never been a fan of XML for this purpose to begin with, but I’m not biased in this review either. Getting the data is a piece of cake. The problem comes in trying to figure out what you need to edit and what you have to take out. It doesn’t do it for you, its nothing but trial and error. Now, this wouldn’t really be a complaint IF the documentation would tell you. But the documentation for the API is just as vague.
Probably my biggest gripe, is the API helper they give you for PHP doesn’t technically support the newest versions of PrestaShop. You have to edit a line to tell it to support version 22.214.171.124 (which is the most recent at the time of writing).
Not only that, but as I said, the API is nothing but trial and error. I spent a good 4-5 hours trying to figure out why I couldn’t insert a product. Even when I enabled debugging/dev mode, the responses were nothing but “Error: 400. This means a bad request.” Okay? What bad request? Nothing in the error logs, nothing else spit out, closest thing I knew is it had to deal with line 214 in the API helper script. Yeah, not great.
Then, I kept getting an error stating bad parameters given. Apparently, there’s some fields that, even though it gives you in the XML, you have to remove yourself. Not very intuitive, and if it wasn’t for it had everything I wanted and I didn’t like the other solutions, I would’ve ditched it.
It gets better, and worse, though at the same time. Right now I still haven’t figured out how to properly add a new image to a product, but I’ll figure that out after Easter.
Going into this project, I knew the server (read: VPS) I’m using for it wouldn’t be very powerful. I had a custom OpenVZ container set up for me that had 256/256 (RAM/burst), 30-40 GB of disk space and ~400 GB of bandwidth. This is optimal for running a small shop, however, which is what it was intended for.
I knew right away when I decided on PrestaShop that I didn’t want to use Apache (which is what Presta recommends). I was already dreading the MySQL usage, so I was deciding on lighttpd and nginx. While I like lighttpd, I wanted to use something different, and went for nginx, as I’ve used it for proxy/load balance before.
The set up for it was pretty easy. Just add PHP support (I used PHP-FPM), and off I went to install Presta. The trouble with nginx (and lightty) though is that they don’t support .htaccess, and they both have their own unique way of handling rewrite rules. Luckily for nginx I found this website: http://winginx.com/htaccess that will convert .htaccess files to usable nginx lines.
Other than that, I had no issues, surprisingly. Install went smooth, set up the database and imported a bunch of test data. I was pleased. For install, I’d give it a 5/5.
Over the past couple of weeks I’ve been helping my fiance start up her own online store and business. The trouble with this is I know Magento is a big-name player in the field, but having first-hand experience with it in the past, I was less than thrilled about setting it up. I was really wanting to run a Python store, so I looked at ones like Cartridge, but the install for it was less than stellar to say the least. So, I ended up catching my eye on Presta Shop and pretty much fell in love with it right away.
It has an API that you can use, which was great as I was wanting to add products and the database structure was nothing but normalization. You could associate products to multiple categories, and since it’d be housing multiple types of products (i.e.: different cards), I wanted them to be able to be a part of different sections. Administration also isn’t bad either, as you can easily install plugins, modules, themes, etc…
However, Presta Shop has a few short comings as well. While it has an API, its very troublesome and error prone (which I will dedicate a whole section on its own to). Installing themes, while easy, can also easily break the layout you have. Also, it runs via PHP and uses Smarty as the template engine for themes. I really didn’t want to use PHP due to performance issues, and Smarty’s template system is…horrible in my opinion. But, I’ll get into this in the appropriate sections.
This series of articles is going to touch on my sysadmin experience of PrestaShop, and at the end I’ll provide a conclusion on what I think of it.
Want to make sure your server is up? Dying to know why the load is 5+ on a 2-core VPS? Using monitoring software.
Yes, it generates overhead. Yes, it is a pain to install and configure sometimes. However, when you want to know why something is breaking or how something is happening, it can be your best friend. Nagios and Cacti are two that I swear by daily, and love using for every bit of usage I can drain out of it.
Software like Shorewall is awesome. It makes managing software firewall easier than eating pie without a fork. However, it has one issue: global variables.
A good example of this happened to a friend not too long ago. In the config files existed some variables (we’ll call them SOME_NET and ANOTHER_NET). However, they were never defined anywhere. Not even doing my favorite grep -r -H “\$SOME_NET” . did any good. As far as I know he still never found out where or what it was defined as, but the horrific troubleshooting still seemed too unfair.
Learn where variables are set, and please keep it there.