Menu
▾
▴
xshop-developer — Discussion about XShop development
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Aric C. <gre...@pe...> - 2003-02-11 19:56:27
|
> First of all, what is the current state of phpshop rewrite in xhtml? I > started a xhtml rewrite too, for a small site, and I'd like to know if it > would be better for me to stop and use your rewrite. Well the first step was to get everything converted to use templates. Most of the important stuff is now templates, which makes it much easier to change the visuals, and to write XHTML or even XML, WAP or whatever templates. I havent yet tried to make the templates truly XHTML compliant, but I have tried to keep them validatable as HTML at the w3c validator. I dont think it would take much more work to get it XHTML compliant. This would be a great contribution of anybody wanted to do it, as its not a super high priority for me at the moment. The admin interface is a different story. Its still mostly not templates yet. But I figured that wasnt as important as the public part of the site. > > I have seen that you are using phplib templates. Beside that, what are the > main differences with current phpshop cvs tree? Is there a demo site or a > real site made using xshop? What is the roadmap? The site for which I am doing all this for (and getting paid for :) is http://www.bbcwireless.com. The closest thing I have to a roadmap is here: http://peoplecatcher.net/article.php3?story_id=34. I definately need to make something better, as I have implemented most of what's there plus a lot more. There are a lot of new features that arent documented yet. some of the major features are as follows: phplib templates and authentication (should work fine with php4 sessions too). Will soon be adding a very robust user / perm scheme with multiple group levels (see the phplib patch at: http://sourceforge.net/tracker/index.php?func=detail&aid=617072&group_id=318 85&atid=403613). Multiple categories to a product ("cross references"). Multiple categories to a category. Set featured/sale items to appear anywhere (another type of cross reference). A more structured navigation system (tabs or links across the top, an optional nav block showing sub category, and sub-sub categories in the "body" area... products list below this). Configurable blocks which can appear on the left or right hand side. Current blocks are a "mini cart", navigation (category), popular products, related products, rss (news feed), raw html. Its easy to extend the classes and make new kinds of blocks. search engine friendly urls. This ranges from 'friendly' (simply changing all '?' and '&' to '/') to downright 'lick your face like a happy dog' (changing a url like: "index.php?page=shop/browse&category=flkh28347t8nasd&product_id=2bh387ug98n" which means nothing to search engines or humans, into something like this: "index.php/shop/browse/phones/nokia/3390" which lets a search engine index important keywords in the url). Use images multiple times without uploading the same image. Use an image select popup window to select existing images. Images on categories. Product options. Create products that can be options to another product. These then show up as a list of options on the flypage, their price being added to the product total price. Currently includes brett's xstats module, but this is going to be replaced by the much better phpopentracker package. Simple caching system. Blocks are cached, and any page can be cached. Uses the database or flat files. That's just what I can think of off the top of my head. > Thanks in advance, > Andres > > ____________ > > Andres Baravalle > http://www.baravalle.it > > Tel: +39 011 6706773 > > ____________ > > Gli uomini d'azione sono poco pratici. > La stessa azione li allontana dalla loro meta. > Paco Ignacio Taibo I > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Xshop-developer mailing list > Xsh...@li... > https://lists.sourceforge.net/lists/listinfo/xshop-developer > |
|
From: Andres B. <and...@li...> - 2003-02-11 08:54:14
|
Hi,
I've seen in phpshop forum of this phpshop fork.
I've downloaded it, but I had some problems in installation and, before
dealing with them, I have some questions.
First of all, what is the current state of phpshop rewrite in xhtml? I
started a xhtml rewrite too, for a small site, and I'd like to know if it
would be better for me to stop and use your rewrite.
I have seen that you are using phplib templates. Beside that, what are the
main differences with current phpshop cvs tree? Is there a demo site or a
real site made using xshop? What is the roadmap?
Thanks in advance,
Andres
____________
Andres Baravalle
http://www.baravalle.it
Tel: +39 011 6706773
____________
Gli uomini d'azione sono poco pratici.
La stessa azione li allontana dalla loro meta.
Paco Ignacio Taibo I
|
|
From: Aric C. <gre...@pe...> - 2002-12-07 01:46:36
|
I had included (with permission) the XStats module by Brett. Unfortunately its in need of rewriting. Instead, I am planning on incorporating the phpOpenTracker (here on sourceforge). This will consist of a module for OpenTracker to handle extra Shop oriented things like products and categories. I'm going to try and make it generic enough to also work with existing phpShop code as well as xShop. Any comments? |
|
From: Aric C. <gre...@pe...> - 2002-10-22 21:31:12
|
I plan to gradualy move over to using the nextid() function (method of = the database class) instead of using the MD5() for creating category and = other ids. That way we dont have such huge ugly urls.=20 Currently working on porting the block engine from phpslash for use with = xShop. May eventualy just merge the two so that we can get basic CMS = features too. Or make one a module of the other. This will give us a block admin where we can select and place the blocks = we want, by category. It will also be easy to add new block types by = just implementing a new sub class -- much easier than making a whole = module. |
|
From: Aric C. <gre...@pe...> - 2002-10-18 20:44:47
|
So, I started working on an installer script for xshop. In order to make the install as simple as possible, I was thinking of = moving everything in the /bin folder into the root (one level up). This = way, the package can be simply unzipped into the webroot and the user = can run the install script which sets up the database and other things. = No files need to be moved or copied, except of course the config file. I dont know if it really is more secure to put everything possible out = side of the web root. That of course is still an option this way. But = people can get up and running quicker and the install script doesnt have = to copy any files which would require chmod'ing etc. Also some people = may not have the option to put things outside of the root anyway. For the other directories that would traditionaly be outside the = webroot, we can put a blank index.html so nobody can see what's in = there. Any objections? |
|
From: Aric C. <gre...@pe...> - 2002-10-16 19:25:38
|
I think we should introduce some structure to the templates directory. = Just plopping them all into one directory will I think get messy and = confusing. We also need to consider different template sets (themes, = WML,XML, etc). =20 It seems like it might also be good to group them by module; that way we = avoid conflicts between modules. So, I'm thinking something like this: templates/themeortype/module. ex: templates/html/shop/browse.tpl |
|
From: Aric C. <gre...@pe...> - 2002-10-16 18:26:45
|
Any idea why these emails just dont seem to be showing up in the mailing = list archive?=20 I want any discussions to be available to late comers and if the = messages dont get archived what's the point? Maybe we should just use the forums.. |
|
From: Aric C. <gre...@pe...> - 2002-10-14 19:04:00
|
OK. So I see there's a few people watching. Lots of folks have = downloaded xshop. But no comments (save one person, Mitchell Sheean, = who has joined the project). Anywho, its time to decide on what = direction we want to go with xshop. The first consideration is compatibility. How compatible do we want to = stay with old phpshop 0.6.x? As you can see thus far, I have built on = the existing base. There are minor changes and additions to the = database. So far this is working, but there are major changes on the = horizon. The original phpshop folk had decided to essentially start = from scratch and from what I understand (I cant find any documentation = on core/commerce) the new phpshop was/is largely incompatible. I'd like = to stay reasonably compatible (a conversion script for the DB would be = nice if possible) but not be saddled with the old db structure. =20 There are clearly problems with the existing db. The product attribute = system is, IMHO, terrible. I've implemented a new "product options" = mechanism which can do much of what the attribute system did, only much = better (I will post some documentation on this). I also plan to = probably incorporate a "simple attribute" system like those discussed on = the phplib forums. Perhaps with these two systems we can just toss the = old attribute system out the window. There are tons of db queries being made and in some cases I'm not sure = how to reduce it. I have thought about all sorts of caching systems = that could be employed, from simply caching the HTML page to having = separate db tables. module registry: almost seems unnecessary and could be replaced with a = "modules.ini" or something. =20 blocks: I have some rudimentary blocks already and had planned to add a = blocks table and associated admin that would allow selecting and placing = blocks based on permissions, category, etc. I had considered adopting = the system used in phpslash (or even merging the two so we could also = have a simple CMS). merge modules: it seems like many modules could be just combined. = Sometimes I have a hell of a time trying to remember where a file is! = It should also be possible to have a module have an admin entry as well = as a public entry but currently (unless I'm missing something) its one = or the other. more thoughts to come. I'm too tired to think of the rest. :o |
|
From: Aric C. <gre...@pe...> - 2002-10-14 18:32:25
|
This is a test. Previous message I sent did not get on the list for = some reason. |
|
From: Aric C. <gre...@pe...> - 2002-10-11 19:13:41
|
Forgot to subscribe myself. :) What you describe would probably work. At least its a short term = solution. We can "patch" the session->url() function (I've done this as an = experiment before and its easy) to basicaly just convert & and ? into = /'s. We would also have to check for any "blank" arguments -- IE = "&category_id=3D&somethingelse=3Detc&" although that really shouldnt be = happening anyway. But a blank like that would throw off everything = after... in the example we'd end up with category_id equaling = somethingelse and etc equaling whatever came next, or nothing, etc.. as = long as kept things consistent like that, and made sure no other /'s got = in there, this should work. |
|
From: Mitchell S. <ms...@fe...> - 2002-10-10 02:49:21
|
Here's what I've done on my test site to make it search engine friendly: http://shop.sheean.com/xshop/main/shop/browse/category_id=3D93317ae14e362= c9c2f0445a134ee5ced Steps to switching from "?page=3Dshop.browse&" to = "/main/shop/browse/..." 1) in your xshop webroot edit or create a .htaccess file with the = following <Files main> ForceType application/x-httpd-php </Files> This tells apache to parse anything called in a url as main as if it = were a .php file with a .php extension.=20 2) Link or copy your main file to main in your xshop folder=20 # ln -s index.php main Now when you call http://www.domain.com/main/ it will play the index.php = file. Now to step 3 3) Enter some url parsing into your main script to separate parameters = from between the incoming forward slashes that you will now use for = urls.=20 // get variables from the page uri $url_array=3Dexplode("/",$REQUEST_URI); //BREAK UP THE URL PATH USING = '/' as delimiter $main =3D $url_array[1]; $page =3D $url_array[2] . "/" . $url_array[3]; The first line breaks up the incoming url with a slash as delimiter = putting each element into array. We call domain.com/main/ in the url now = so $main will be the first in the array. Not being used but it's there = for illustration. We then take element 2 and 3 and put them back = together with a slash in the middle setting that to the $page variable = the way xshop likes it.=20 I don't know if this will work with the whole site bit it may be worth = exploring.=20 http://shop.sheean.com/xshop/main/shop/browse/category_id=3D93317ae14e362= c9c2f0445a134ee5ced The above will set $page =3D shop/browse other variables come thru so = far. ~mds |
