The 2012 season for OXID developer meet-ups started in Hamburg on January 13. Sigmar Kress from Rhinos Media organized the location and we set up a page on OXIDforge for gathering information about participants and ideas for talks.
Although we announced the event relatively late, more than twenty people came to the meet-up. I was glad to see partners and shop owners sending their developers and project leaders to the event.
As previously announced, Joscha started talking about his TOXID project and how it can be used to integrate Typo3 content with OXID eShop (and vice-versa). We also discussed integration with other content management systems like WordPress and Joomla using TOXID. If you’ve been using TOXID for this purpose, please feel free to share your insights, or write a tutorial about it, on OXIDforge.
Later in the evening, I spent some time talking about OXID’s development plans for 2012, including OXID eShop 4.6.0 beta, and we had an interesting and spirited discussion about this.
Another big topic also came up: the idea of developing another admin panel with the community, which was first born at the OXID Unconference in May 2011. Now, in Hamburg, almost everybody who was interested in this venture was in attendance, and so we agreed on a kick-off meeting and coding event between March 9-10. If you are interested in supporting this project and have some spare capacity, please contact me.
The bottom line: we held a very successful and informative developer meet-up again. If you would like to see a similar meet-up in your location, please talk to me about the date first. The rest is pretty simple: just reserve a table for enough people and help to spread the word.
Again and again I see my website being found with the key word “rewritebase oxid eshop”. Obviously this seems not to be a clear case. Let me explain it:
The OXID eShop strictly uses so called re-written URLs, known as “permalinks” in WordPress. In opposite to e.g. WordPress, you cannot choose between “regular” URLs and re-written URLs, it’s use is assumed and this, absolutely makes sense: Who wants to run an online store without wanting to be ranked on top of the known search engines?
Nice, isn’t it? In a matter of fact, your product details page will rank much higher in any search engine!
To achieve this effect, your webspace or server has to fulfill some requirements before you can set up OXID eShop:
- The component “mod_rewrite” has to be installed. You can check this easily with a simple file – let’s call it “check.php” – that you can load onto your server via FTP contents the following:
<?php phpinfo(); ?>. Fire up your browser and insert http://www.yourstore.com/check.php now, search for “mod_rewrite”. If you cannot find anything, turn to your hosting provider. Don’t forget to ditch this file once you saw it – the information provided opens doors to all the hackers.
- Check, if you really uploaded the delivered file .htaccess. Files with a leading dot are marked as hidden in the Unix world, so at a MAC, and will not be uploaded by default.
- Some hosting providers do not allow an own .htaccess file. Request it!
- Some hosting providers request an additional entry into the .htaccess file, called “RewriteBase”
In this case, replace
if you run a sub-folder.
If there still problems remaining, turn to the forums, I’ll be there
Actually I wrote the blog post “The Scuttles at Anker Leipzig” to check out the module “Upcoming Events” whether WordPress is working nice for bands and artists that want to run an interactive website instead of a stupid static one.
You know, I don’t really like that upcoming Flash intro pages (that you might skip in best case) followed by links like “Band”, “Members”, “Sound”, “Guest Book”, “Imprint”, the complete design held dark-colored. You can find that scheme for every bl**dy band, even for the most wanted.
“Band” and “Members” usually are rarely updated, “Sound” is mostly illegally implemented and “Imprint” seems to be a German legal invitation against common sense in most cases. The only interactive part seems to be the “Guest Book” where you may find stuff like saw you yesterday and really appreciated it, if you are lucky.
Ages ago, Verena brought up the idea of heaving a weblog for a band homepage instead:
- Post your upcoming events like On this and that date, we will have our next gig at [location]. We are very proud to perform there again because [reason]. The plugin “Upcoming Events” additionally delivers an event calendar as a widget to your site bar. The interesting thing, especially for band who don’t perform every day / week is: Upcoming events will be listed and treated more like a topic then a calendar. The only thing you have to do is to define a custom field
date and the value for it.
- Once your gig is done, publish a new post: Yesterday we performed at [location]. It was lots of fun, we liked you as audience, here are some pictures [3-4 pictures/videos].
- From now on, people might react with certain comments and fill up your specific event page with contents. Comparing to a guest book entry (the word itself sounds obsolete somehow) that method looks like really search machine relevant, doesn’t it?
For me, it looks like a real alternative. But talking to the band guys and musicians, I really found reservations: They do not even got what I was talking about! Most of them just know how to turn on a computer. Most feel like they have to have a website. Talking about interactivity and maybe weblogs is too much for them, even if you would explain how to update the website’s content, simply sending an e-mail. This would probably be the most suspect thing.
What to do?
Moving WordPress from one server to another is pretty simple. It actually shall not take longer as five minutes following this steps:
1st step – server environment
Check if the basic server environment is the same as you had on the server before, especially for
- PHP-Version (some modules require PHP5 and higher)
- Database-Version (maybe important for your data import)
- special PHP modules (e.g. if you use permalinks, make sure mod_rewrite is activated and running)
If you feel like there is everything alright on the new server, you may want to go ahead.
2nd step – the database
- Export the WordPress database of your former server to a sql-file or to a compressed sql-file. You may either use a GUI tool like phpMyAdmin or the terminal.
- Import this (compressed) sql-file into the database on your server. Use the import function of your GUI tool to do so or the terminal if you are able to login with putty.
- Change the path settings: In the new database of your webserver, you shall find a table called
option_name="siteurl" you will find the path settings you entered during the initial installation process
3rd step – the files
- Connect to your previous server via FTP and download the files of your WordPress document root.
- Upload this files to you new server.
- Using your FTP client, go to the new server’s WordPress document root and open the file
wp-config.php. Adapt the new server’s
database name, the
database server (if needed, localhost is used mostly), the
database user name and the
- Check the permissions needed for proper work of your new system:
wp-config.php has to be set to 0644
- for pucture uploads etc,
/wp-content/uploads/ shall be writable (0755 or 0777)
- for updates or automatic plugin installation,
/wp-content/upgrades/ shall be writable (0755 or 0777)
- Take care: In Unix-World, e.g. if you are using any Linux or Mac (AFAIK with a FreeBSD under the hood), dotted files are not shown and not copied by default using your FTP client. So the
.htaccess file which is important if you activated the so called “Permalinks” may be not transferred. Make sure it is on his place.
- Go to Admin -> Settings -> Permalinks. In case you activated this options, at the bottom of this page the current content of your
.htaccess appears like it should be. Probably the value for your RewriteBase changed. Copy this content and overwrite the
.htaccess on your server.
You are done! Congratulations hero!