Re: [oxid-dev-general] Yes! I made it! [T-HYYJ56EF4K-68]
Wow! Very nice!!! :) Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- ACHTUNG: seit 01.08.2011 neue Anschrift: -- anzido GmbH Iltisweg 3 44269 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 18.10.2011 09:05:00 Von: Raimund Lang r.l...@haller-stahlwaren.de An: dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] Yes! I made it! Vorgang: T-HYYJ56EF4K-68 Hi folks! Finally I got the confirmation, that Oxid eShop has been added to the Open-Source one-click-installations in the backend of Domainfactory Hosting. Now df-customers can install the shop with just one click in their backend! The only offered shop-software was the OS-Commerce-Shop until now. As Domainfactory is one of the biggest hosters in Germany, this will for sure support in spreading the Oxid eShop! Greez Ray Haller Stahlwaren GmbH Am Gartennest 1 74544 Michelbach/Bilz --- Tel.: 0791/47003 Fax : 0791/47005 www.haller-stahlwaren.de --- Sitz: Schwäbisch Hall Registergericht: Stuttgart HRB 570131 Geschäftsführer: Hermann Hebsacker, Karin Hebsacker ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Ats.: Custom components option [T-X651XHZ1GS-75]
Hi,
you can actually do this quite easily. Just add the following to the end of the
config.inc.php:
if ( file_exists( dirname(__FILE__) . '/config.inc.local.php' ) ) {
include( dirname(__FILE__) . '/config.inc.local.php' );
}
This won't throw an error if the file does not exist. If it exists, it will
just include it. Putting it at the end of the config.inc.php means that you can
override anything you like, e.g. database connection settings and shop urls...
Best regards from Dortmund!
Robert Rosendahl | Entwicklung u. Support
--
anzido GmbH
Kirchhörder Str. 12
44229 Dortmund
Tel.: 0231 - 60 71 079
Fax.: 0231 - 60 71 081
Mobil:0176 - 8325 1488
Email: i...@anzido.com
Web: http://www.anzido.com ( http://www.anzido.com/ )
USt-ID: DE257982972
Geschäftsführung: Andreas Ziethen
Amtsgericht Dortmund HRB 20883
-Ursprüngliche Daten-
Datum: 05.07.2011 13:46:18
Von: development developm...@orca.ch
An: dev-general@lists.oxidforge.org dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Ats.: Custom components option
Vorgang: T-X651XHZ1GS-75
Hello David
Great ideas!
By the way I'm currently thinking about staging solutions in general. How to
solve the transition of data configuration etc between development and
testing environment or testing and production environment for example.
I think your solution could be a first step to enable OXID to be capable of
this from its core.
Though I personally don't like to fiddle around with Apache (though I could
in most cases). Also to do it by .htaccess I don't like.
I would prefer to set local settings in a config file called
config.local.php
or something.
The global config (as we know it until now) I would put into
config.global.php.
And a better place for the custom components (and other data in the future)
comes to mind:
config.custom.php.
And I also second your commend about putting these config files into a conf,
config or configuration sub directory within the root.
So if there is no config.local.php the shop just takes all configuration from
config.global.php. If there is, you can overwrite selected parts of all
configuration by the local settings.
The same goes for the custom settings.
We could go even further and allow a
config.default.php
but I'm currently not sure what to put in there.
May be aAllowedUploadTypes or other very rarely overwritten configuration.
What do you think?
Grüsse aus Basel
Marc
ORCA Services AG
Herrenmattstrasse 26
CH-4132 Muttenz
Office Basel: Aeschengraben 10, CH-4051 Basel
marc.wue...@orca.ch
T. +41 61 205 80 80
T. +41 61 205 80 73 (direkt)
F. +41 61 205 80 81
www.orca.ch, www.orca-services.ch
We convert your visitors into customers.
-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von
daniel.schlichth...@mayflower.de
Gesendet: Freitag, 1. Juli 2011 23:16
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Ats.: Custom components option
Hi readers and developers,
I really appreciate the idea of adding custom components via the
configuration. That's much better than all the workarounds which cause a
great overhead just to hack a simple setting in oxubase.
As a general thought on this I would go a step further:
a developer has to deal with local, testing, continous integration,
staging and productive environments and - of course - all need different
settings. So we had to find a way to handle different environments which
need different configuration settings.
The way we solved this, is to set up an environment variable in
apache's vhost.conf like e.g.:
SetEnv APPLICATION_ENV production
(In most cases one could also do this using the .htacess file)
In config.inc.php we added something like this at the end:
// additional configuration values
$stage = getenv('APPLICATION_ENV');
if (is_readable(SHOP_PATH .'/config.' . $stage . '.php')) {
include SHOP_PATH .'/config.' . $stage . '.php';
}
This way you do have all possibilities to extend or replace
configuration settings depending on the environment, the current
instance is running on. Additionally our customer has a central place to
edit configuration settings and we don't need to create an admin view
for every single setting (time = costs).
It is somehow similar to the way the language array is extended if a
file exists in out/theme/language/. Maybe this is a way that could make
it into the core? If the file doesn't exist there is no disadvantage
(except some microseconds to find out that the file doesn't exist).
Additionally I would place all configurations in a sub folder called
config to clean up the htdocs-root (included files shouldn't be in the
document root).
In contrast to Marc I do feel, that a configuration file is the correct
place to place this. Because that's what we do
Re: [oxid-dev-general] Merging old and current baskets [T-1KW022X2HH-26]
Hi, I'm not sure if this is making things too complicated for users, but the idea sounds good - it is a bit irritating that currently items appear in the basket without any notice ;-) Since this might make the ordering process more complicated, it would be good if the merge would be optional (e.g. if you could configure this in the admin and select whether to never merge, always merge, show a notice or ask the user what to merge). Another thought: if you allow the user to merge the baskets, then it would be neat if the user could select which products to merge into the basket, and which products to put on the notice list (if it is activated in the shop). I believe Amazon offers the option of moving things between the notice list and the basket in the basket overview. Beste Grüße aus Dortmund! Robert Rosendahl | Entwicklung u. Support -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com/ (http://www.anzido.com) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 23.06.2011 15:32:20 Von: Mavydas Skuodas mazvy...@nfq.lt An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] Merging old and current baskets Vorgang: T-1KW022X2HH-26 Hi, This feature is nice to have, but it has to be more intelligent, more customizable by shop owners. User scenario should look like this: If user logs in and currently donrsquot have anything in the basket, Oxid should show message (at notice level) that user have had some basket items before. if user reacts to that notice, he have few options to choose: review all content of that basket, (in that window he could add some of the items of that basket) continue using old basket discard all items. If user have something in the basket, oxid should show also the message in notice, but this time if some items are the same, message text differs, and says something like ldquoPreviously you also added item X and other N items, Merge? rdquo. Notice level is important that user will not be distracted from buying that he is planning to do now (he is in 2 step to the complete order). Dialog should suggest the same options as before: review all content of that basket, (in that window he could add some of the items of that basket) add most popular item (in Oxid case, this should be extendable very easily as it depends on shop owner business logic ) discard all items. Mavydas From: dainius.bige...@oxid-esales.com (Dainius Bigelis) Sent: Thursday, June 23, 2011 3:33 PM To: dev-general@lists.oxidforge.org Subject: [oxid-dev-general] Merging old and current baskets Hi, Currently welsquore considering about concept, how to handle basket saved for user from previous session (when user not finishes the order, so itlsquos stored to DB). One of the ideas is written in the bugtrack entry: https://bugs.oxid-esales.com/view.php?id=2260 hellip that baskets from the previous session and current order would be merged using simple rule. Though tjungl (see comments from him next to the bug entry) is right that this concept still would be confusing for customer as some stuff may occur in the current basket unexpectedly. So suggestion is to ask user if he want to merge baskets or no. Going further ndash would be even better to give user possibility to choose which of the products should be merged, which not. The vision is like displaying content of two baskets and moving it between right - left - or cancel some. Or just display popup with content of previous basket and checkboxes for products, which should be merged. Anyway such feature would be additional stuff to the order processing area. But ndash what are your ideas about that: - Do we need such feature at all? Would it be useful? - Or better just apply some simple rule for merging and inform about changes done? - Would it affect/reduce the conversion rate (by adding more complex content to critical place)? - Or maybe you have better ideas how to handle that in the simpler way? Best regards, Dainius Bigelis ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] User registration after Newsletter subscription [T-JQCJ4YW6ED-79]
Hi, 3.a) sounds correct to me: a newsletter checkbox is offered, and independently of what the user chose before, if the user now does not check the newsletter checkbox now, then this is a decision not to receive the newsletter. This is an opt-out that has been deliberately chosen by the user when filling out the registration form. Apart from this, I don't think there is any other way to handle this: users that didn't register for the newsletter before need the option to chose whether to receive the newsletter when registering, and you cannot look up an existing newsletter registration until the user has entered an email address in the registration form and submitted it. The only way to deal with this in another way would be an additional screen asking whether to really cancel the previous newsletter subscription... Another thing to take into account is that if a user deliberately registers without an account (without setting a password), then pre-selecting the newsletter checkbox or asking whether to cancel an existing newsletter registration would appear as a clear violation of privacy expectations: when ordering without opening a customer account, i would not expect the shop to know anything about me the next time i interact with the shop ;-) 3.b) I would consider this a bug. If the email address has been previously registered for the newsletter and the opt-in has already been confirmed, then there is no reason for a second opt-in for the same email address. Beste Grüße aus Dortmund! Robert Rosendahl | Entwicklung u. Support -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 12.05.2011 22:00:13 Von: .NFQ | Martin Bornack m.born...@nfq.de An: dev-general@lists.oxidforge.org dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] User registration after Newsletter subscription Vorgang: T-JQCJ4YW6ED-79 Hi, we stumbled upon a certain shop behavior concerning the newsletter registration which is a bug in our eyes and just wanted to know if you see it differently or agree with us. ;) 1. A user comes to the shop and subscribes to the newsletter. - oxuser entry and oxnewssubscribed entry (oxdboptin = 2, oxsubscribed = now(), oxunsubscribed is empty) added. 2. The user clicks the double optin. - oxnewssubscribed entry is changed (oxdboptin = 1). 3. Then the user registers in the shop ndash no matter if he registers with or bdquowithout accountldquo (bdquowithout passwordldquo is more like it) and a. does NOT set the NL flag (hellipagain ndash he is already registered) - oxnewssubscribed entry is changed (oxdboptin = 0). b. DOES set the NL flag - oxnewssubscribed entry is changed (oxdboptin = 2, oxsubscribed = now()). User getrsquos a new double optin mail In the first case the user wonrsquot get the NL anymore without any notice, in the second case he has to revalidate his emailhellip Best regards, i.A. Martin Bornack - [ . nfq] netzfrequenz GmbH manager technical development martin bornack bergiusstraße 13 86199 augsburg telefon: +49 (821) 9000 611 fax: +49 (821) 9000 619 http://www.nfq.de http://www.nfq-module.de - ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Multilang-Views in OXID eShop4.5.0 [T-I7FRVSSNU2-09]
Hi, I took the liberty of reporting this as a bug ;-) You can follow the issue here: https://bugs.oxid-esales.com/view.php?id=2840 Best regards from Dortmund! Robert Rosendahl | Entwicklung u. Support -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 10.05.2011 11:54:41 Von: Thomas Oppelt t.opp...@superreal.de An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] Multilang-Views in OXID eShop4.5.0 Vorgang: T-I7FRVSSNU2-09 Hi guys, anything new on this? regards thomas Am 28.04.2011 20:14, schrieb anzido GmbH: -- superReal GmbH Agentur für Neue Kommunikation Borselstraße 16 f 22765 Hamburg T: 040 / 80 81 80 3-13 oder T: 040 / 87 09 68 87 F: 040 / 80 81 80 3-10 http://www.superReal.de Geschäftsführer: Oliver Cloppenburg, Volker Will Amtsgericht Hamburg HRA 74092 ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] oxseo fullscan [T-6VJH77ICB7-35]
And some from me: Shop 1: Field_name Min_value Max_value Min_length Max_length Empties_or_zerosNulls Avg_value_or_avg_length Std Optimal_fieldtype live_babymarkt.oxseo.OXSTDURL ?cl=azsitemapamp;anid=c341929fd71d24d53e11f1fdf99c60a3 index.php?cnid=oxmoreamp;cl=alist 17 113 0 0 78.9497 NULLVARCHAR(113) NOT NULL live_babymarkt.oxseo.OXSEOURL 11/ xKinderwagen-Babytragen/Zwillingswagen-Geschwisterwagen/ABC-DESIGN-Tragewanne-zum-Zoom-Orange-black-Kollektion-2010.html 2 191 0 0 83.1851 NULLVARCHAR(191) NOT NULL count(*) 287345 count(*)avg(length(oxstdurl)) max(length(oxstdurl)) avg(length(oxseourl)) max(length(oxseourl)) 287345 78.9497 113 83.1851 191 Shop 2: --- Field_name Min_value Max_value Min_length Max_length Empties_or_zerosNulls Avg_value_or_avg_length Std Optimal_fieldtype usrdb_worhppxo2.oxseo.OXSTDURL /Zuckerwaren/Brausepulver-Bonbons/Ahoj-Brause/amp... index.php?cnid=oxmoreamp;cl=alist 17 172 0 0 89.4872 NULLVARCHAR(172) NOT NULL usrdb_worhppxo2.oxseo.OXSEOURL 1-Alles-fuer-die-Schultuete.html Zuckerwaren/Zuckerwatte-im-Becher.html 2 135 0 0 53.6110 NULLVARCHAR(135) NOT NULL count(*) 66083 count(*)avg(length(oxstdurl)) max(length(oxstdurl)) avg(length(oxseourl)) max(length(oxseourl)) 66083 89.4873 172 53.6112 135 Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 27.04.2011 13:06:27 Von: arunasValakevicius sarunas.valaskevic...@oxid-esales.com An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] oxseo fullscan Vorgang: T-6VJH77ICB7-35 Hi, we are currently fixing this issue, https://bugs.oxid-esales.com/view.php?id=2740 . The solution to change oxstdurl and oxseourl fields to varchar(2048) currently sounds the best. Also, to select good indexing length we would need feedback about usual lengths of these data in real shops. Please help us by gathering some statistical data about these data in your shop database. Could you please run the following query and send us the results? (just post the results here in the dev general) SELECT oxstdurl,oxseourl FROM `oxseo` PROCEDURE ANALYSE(1,1); together with data count returned by SELECT count(*) FROM oxseo; if it wouldn't work (e.g. some mysql clients automatically append limit clause after procedure), you could also use simple sql such as: select count(*), avg(length(oxstdurl)), max(length(oxstdurl)), avg(length(oxseourl)), max(length(oxseourl)) from oxseo; Note, that on huge databases these selects will increase load. Especially if your database is already under heavy load, it would be best to run it on a separate db clone or at least on more idle hours. Regards, Sarunas On Tue, 2011-04-26 at 16:01 +0200, anzido GmbH wrote: Hi, I think it would be useful, to change the oxstdurl to an varchar-type and impose this column with an index? It's not only useful - it's absolutely essential if you have a big shop with much traffic! Also you should take care that searching for seo urls is done only if the std url CAN HAVE any seo url. For example if the std url looks like: index.php?force_sid= OR index.php?stoken= OR index.php? cl=search and so on - there is NO seo url and searching for it is absolutely needless and a waste of ressources. On one of our bigger projects we reduced the total number of sql queries by nearly 20%! Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] oxseo fullscan [T-6VJH77ICB7-35]
Hi, I think it would be useful, to change the oxstdurl to an varchar-type and impose this column with an index? It's not only useful - it's absolutely essential if you have a big shop with much traffic! Also you should take care that searching for seo urls is done only if the std url CAN HAVE any seo url. For example if the std url looks like: index.php?force_sid= OR index.php?stoken= OR index.php? cl=search and so on - there is NO seo url and searching for it is absolutely needless and a waste of ressources. On one of our bigger projects we reduced the total number of sql queries by nearly 20%! Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 26.04.2011 15:30:11 Von: Tobias Merkl me...@shoptimax.de An: dev-general@lists.oxidforge.org dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] oxseo fullscan Vorgang: T-6VJH77ICB7-35 Hey community, does anybody have an idea, why the oxseo-table doesnŽt have an index? I think it would be useful, to change the oxstdurl to an varchar-type and impose this column with an index? Kindest regards Tobias * shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Tel(09 11) 2 55 66 - 25 Fax(09 11) 2 55 66 - 29 eMail me...@shoptimax.de Webwww.shoptimax.de * Geschäftsführung: Friedrich Schreieck Ust.-IdNr.: DE 814340642 Amtsgericht Nürnberg HRB 21703 * ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] oxpec_class_file_paths.php not completelywritten [T-0FEUPB2M55-29]
Hi, the problem might have resulted from insufficient webspace in your case, but in other cases with plenty of space left, it also occurrs. We have at least two customers with OXID EE 4 where this problem appeared from time to time. I guess it has something to do with different worker threads trying to write the file at the same time, but like Aurimas already wrote, it's already in the bugtracker. As a workaround, you can look for the filename (class_file_path) in the source code and comment out the code that writes and reads that file. It's in the core cache class if I remember correctly, and commenting out the code didn't cause a measurable performance loss in those two shops (even though in that case the class file paths have to be detected by the autoloader each time). Best regards, Robert -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 01.04.2011 10:21:12 Von: Kai Gazmaga kai.gazm...@vektordesign.de An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] oxpec_class_file_paths.php not completelywritten Vorgang: T-0FEUPB2M55-29 Hi Tobias, did you read my reply from 2011-03-12 12:26? The problem was insufficient Webspace here, so the file could not be fully written. Regards, Kai VektorDesign - Online-Shops und Programmierung Kai Gazmaga Neue Strasse 83 89 073 Ulm Tel.: +49 731 - 3781953 Fax: +49 731 - 3781952 Mail: i...@vektordesign.de Web: www.vektordesign.de Am 31.03.2011 12:05, schrieb Tobias Merkl: Hey guys, do you have more information or has somebody else the same problem? We also have this hitch in some shops (4.4.6 and higher). Kindest Regards Tobias Merkl Software-Entwicklung * shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Tel (09 11) 2 55 66 - 25 Fax (09 11) 2 55 66 - 29 eMail me...@shoptimax.de Web www.shoptimax.de * Geschäftsführung: Friedrich Schreieck Ust.-IdNr.: DE 814340642 Amtsgericht Nürnberg HRB 21703 * Von: dev-general-boun...@lists.oxidforge.org [ mailto:dev-general-boun...@lists.oxidforge.org ] Im Auftrag von Aurimas Urbonas Gesendet: Freitag, 25. März 2011 20:36 An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] oxpec_class_file_paths.php not completely written Hello, https://bugs.oxid-esales.com/view.php?id=2214 Best regards, Aurimas On Fri, Mar 25, 2011 at 11:56 AM, Kai Gazmaga kai.gazm...@vektordesign.de wrote: Hi! today I came across a very irritating phenomenon: The shop of a customer was offline with an error-message that said, something in /tmp/oxpec_class_file_paths.php was wrong. Looking into the file made me see, it was not fully written. Line 65 looks like this: 'oxdeliverysetlist' = '/var/www/web4/html/LIVE/cor deleting the file solved the problem. The customer told me the problem occurs for about a week after uploading article-pictures - not allways, but for some articles. Suddenly the complete system is unavailable (shop and admin). I will try to find out a bit more, but any hint would be helpful, becaus I did not find any bit of information on google or the forums. Regards, Kai Gazmaga VektorDesign - Online-Shops und Programmierung Kai Gazmaga Neue Strasse 83 89 073 Ulm Tel.: +49 731 - 3781953 Fax: +49 731 - 3781952 Mail: i...@vektordesign.de Web: www.vektordesign.de ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Sub-Shop question: attributes [T-YXA8O6RHNO-06]
Hi, there's actually no reason for an oxobject2attribute view, because the entries in this table are mapped to the attributes, which are already taken from the attribute view. Or to put it another way: the attributes are assigned to subshops, their values are assigned to the attributes (and thus already assigned to the subshops implicitly). Beste Grüße aus Dortmund! Robert Rosendahl | Entwicklung u. Support -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 15.03.2011 01:22:10 Von: M. Bladowski mbladow...@macropage.de An: dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] Sub-Shop question: attributes Vorgang: T-YXA8O6RHNO-06 hi all, there are several views to map stuff from the parent shop to the sub-shops: - oxv_oxarticles_2 - oxv_oxattribute_2 and so on... but i cannot find a oxv_oxobject2attribute_2 - why the oxv_oxattribute_2 exists, why not the other part ? and i am also confused because oxobject2attribute has not OXSHOPINCL - why ? ;) so is there any chance to see the attributes of the parent shop in one of the sub-shops ??? thanks for any help. regards, micha -- Mit freundlichen Grüßen MACROPAGE e.K. Michael Bladowski Maximilianstrasse 6 93047 Regensburg Mobil: 0179-2301067 Voip: 0941-56955585 mbladow...@macropage.de http://blog.macropage.de [[[ FOLLOW ME: http://twitter.com/michabbb ]]] Handelsregister Regensburg HRA 7490 · Finanzamt Regensburg DE 210758353 ___ Unsere Dienstleistungen: Internetserviceprovider, Entwicklung u. Programmierung, Web- und Grafikdesign, Schulung, Beratung, Problemlöser ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] updateApp warning message [T-O8VKTSAZSO-37]
Hi Dainius, I know that the updateApp usually deletes itself (or its contents) after the update. What I meant was the message that you see in the frontend while the updateApp is on the server. We have some shops with so much traffic that I fear it will be irritating to the users to see the message in the frontend while I run the updateApp. Therefore I would rather have the message about the updateApp only in the admin backend and not in visible in the frontend. From my point of view the shop customers should not notice at all that an update is being done on the server, except maybe that the shop is a bit slower because some database tables are being updated... ;-) Beste Grüße aus Dortmund! Robert Rosendahl | Entwicklung u. Support -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 29.12.2010 16:37:16 Von: Dainius Bigelis dainius.bige...@oxid-esales.com An: entwickl...@anzido.com entwickl...@anzido.com Betreff: RE: [oxid-dev-general] updateApp warning message Vorgang: T-O8VKTSAZSO-37 hi, We found your message in dev-general about this case. Could you please tell more about the case when you still get this error message in frontend? - Between what versions you made an update? - what rights/permissions are set on this dir during update? - update went properly, just files left not deleted? (as we have implemented the deleting also)? Because I cannot reproduce this localy (getting message only in Admin or just after update is done, in the same UpdateApp screen). And in some of latest Shop versions we have fixed some bugs related to that... if there is still something left, would be good to polish that behavior... Best regards, Dainius Bigelis ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
[oxid-dev-general] updateApp warning message [T-O8VKTSAZSO-37]
Hello, when performing a shop update and copying the updateApp into the shop, then the shop frontend shows a red warning message, telling everybody that the updateApp folder should be deleted. I think this security warning belongs into the OXIDforge documentation and (along with the system health warnings) into the admin area, but not into the frontend. Letting an updateApp lying around in a shop may be a security leak, but I believe that the shop's customers are not the correct audience for this (at least not until after some period of grace after the shop owner has been informed). Beste Grüße aus Dortmund! Robert Rosendahl | Entwicklung u. Support -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] oxemail: put function calls intoproperty [T-D3898PM6XJ-46]
Hi Arvydas,
thx for your response.
What exactly do you mean or want to know by:
The question is how will look your function which trigger some special
functionality before sending an email dependent on the type of email?
?
Beste Grüße aus Dortmund!
Andreas Ziethen | Geschäftsführung
--
anzido GmbH
Kirchhörder Str. 12
44229 Dortmund
Tel.: 0231 - 60 71 079
Fax.: 0231 - 60 71 081
Mobil:0176 - 8325 1488
Email: i...@anzido.com
Web: http://www.anzido.com ( http://www.anzido.com/ )
USt-ID: DE257982972
Geschäftsführung: Andreas Ziethen
Amtsgericht Dortmund HRB 20883
-Ursprüngliche Daten-
Datum: 14.10.2010 13:21:52
Von: Arvydas arvydas.vap...@oxid-esales.com
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] oxemail: put function calls intoproperty
Vorgang: T-D3898PM6XJ-46
Hello,
thanks for your ideas, that's a good hint for refactoring/improving. Sadly
we cant just change code the way you want
due to compatibility with previous shop versions, thus we will improve this
code in next major releases.
If you are free to change/extend your own code and able to replace current
mail function calls you may use a bit tuned
your suggested executeSendMailFunction() function:
public function executeSendMailFunction( $sFunction, $aParams )
{
return call_user_func_array( array( $this, $sFunction ), $aParams );
}
The question is how will look your function which trigger some special
functionality before sending an email dependent on the type of email?
Best regards,
Arvydas Vapsva
--
From: anzido GmbH entwickl...@anzido.com
Sent: Sunday, October 03, 2010 12:24 PM
To: dev-general@lists.oxidforge.org
Subject: [oxid-dev-general] oxemail: put function calls into
property[T-D3898PM6XJ-46]
Hi,
several times we had projects where one of the requirements was to trigger
some special functionality before sending an email from oxemail class.
Especially if this special functionality is dependent on the type of
email - it is quite cumberesome to solve this, cause in the _sendMail()
function you do not know which type of email has to be sent.
So I would like to have a property which is filled by the name of the
function which has been called before, like this:
$_sActMailFunctionCall = ;
public function sendOrderEmailToOwner( $sOrder, $sSubject = null )
{
$this-_sActMailFunctionCall = sendOrderEmailToOwner;
...
}
Of course you could even build a small sort of factory function which
would be called by the several view classes, doing this job - so you would
not have to put a new line of coude into each mail function - like this
for example:
in class oxEmail:
public function executeSendMailFunction( $sFunction, $aParams )
{
$this-_sActMailFunctionCall = $sFunction;
$this-$sFunction( $aParams);
}
in oxOrder::_sendOrderByEmail():
$oxEmail-executeSendMailFunction( sendOrderEmailToOwner, $aParams );
Doing this would give developers a whole bunch of nice possibilities. For
example you could write a central function to manipulate email subjects
dependent on the type of email. Or you could save the content of special
email and so on ...
At the moment all this is possible - but you have to overload a lot of
functions for this to detect the type of email.
Using the factory function would mean that the several send-functions
would not have to be changed appart from the parameters given to them. But
even this could be done inside the factory, which then would have to
prepare the params for the single calls.
The factory way in my opinion would be the best one regarding code
layout, but I see that in terms of compatibility to old versions and
modules this could cause some trouble .. - So perhaps as a first step you
could just add the first mentioned line of could to each function?
If somebody has got a better idea to solve this - let me know!
Regards,
Andreas
--
anzido GmbH
Kirchhörder Str. 12
44229 Dortmund
Tel.: 0231 - 60 71 079
Fax.: 0231 - 60 71 081
Mobil:0176 - 8325 1488
Email: i...@anzido.com
Web: http://www.anzido.com ( http://www.anzido.com/ )
USt-ID: DE257982972
Geschäftsführung: Andreas Ziethen
Amtsgericht Dortmund HRB 20883
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Suggestion: Put modules from database intoan PHP File [T-DIA317V99U-31]
Hi Chris, I am not really sure but I think: (1) is done just because using the oxconfig stuff is a very simple way to store the module configuration. And oxconfig values are encoded because there might be some confidential parameters in there, e. g. if you store account data for smtp or for other modules (soap access etc.) into oxconfig table. So if the database would be hacked those parameters could not be read in a simple way (allthough everybody who knows a little bit about oxid can decode them ...). (2) I think that the OXID developers wanted to prevent some classes from beeing overloaded cause they are sort of basic for the whole shop functionality and can easily screw the whole thing up. So I guess this had been done to have some control about such essential stuff. But that's just a guess ... Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 03.11.2010 18:24:32 Von: Chris Jolly cpjo...@yahoo.com An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] Suggestion: Put modules from database intoan PHP File Vorgang: T-DIA317V99U-31 Am I missing something, because this seems very simple to me... (1). Why is it necessary to encode the list of plug-in modules and to then store this in the database ? (2). Why is it necessary to start the framework in such a way that 5 classes can't be extended ? If there are no good reasons for either and assuming the fix is simple, why shouldn't we ask OXID to make this change ? From: Christopher Simon si...@topconcepts.com To: dev-general@lists.oxidforge.org Sent: Wed, November 3, 2010 11:22:33 AM Subject: Re: [oxid-dev-general] Suggestion: Put modules from database into an PHP File Hi, I know that it works with a wrapper, still this doesn't solve the synchronization issue within development teams. Such kind of emergency scripts, help for the moment, but they don't fix the source of the problem. btw you can also initiate the shop framework for such a script. Am 03.11.2010 10:40, schrieb Stefan Krenz: Hi, you can edit the module list outside from OXID. We need two wrapper classes, one for config.inc.php (named as ConfigWrapper) and one for oxconfk.php (named as ConfKWrapper). With this classes you can get the required information: - ConfigWrapper-dbHost - ConfigWrapper-dbName - ConfigWrapper-dbUser - ConfigWrapper-dbPwd - ConfKWrapper-sConfigKey (needed to en-/decrypt the aModules DB entry) Connect to the database, get the content of 'OXVARVALUE' from 'oxconfig' with the MySQL function 'DECODE' (use 'ConfKWrapper-sConfigKey' for the second argument). You will get the serialized array within the module list. Unserialize and modify it and put the new serialized array into the database. Don't forget the encryption with ENCODE. This will also work with the Zend Guard encoded versions of OXID. Regards Stefan Krenz Am 03.11.2010 08:53, schrieb Christopher Simon: Hi, when you work in a team at a shop project, you often have the problem that if some team member adds a new module which is used in templates and stuff the other team members have to be noticed that they have to add new the new modules in their respective test database. (we work with virtual machines for each dev). In addition, if a user adds a Module which breaks the shop somehow, he sometimes isn't able to remove this module because it broke some component which is mandatory for the admin area. The module array is saved as a blob, which makes it a little tricky to edit modules without the admin area. Because of this, we do it like this: Delete (or rename) the aModules entry in the database and put this line in config.inc.php: $this-aModules = tc_modules($this); tc_modules includes this nice little PHP File: ?php return array( 'oxbaseshop' = array( // standard 'oxorder' = 'invoicepdf/myorder', ), ); With this small modification, you are able tu put your modules in projects under version control (with SVN), and work much more effective in teams. If you now include a module which breaks the shop in any way, you are able to simply remove it by editing the file. I would like to suggest this for 4.5. Only downside: Some module installers would not work anymore. I know that you are working on automatic module installer stuff, but i would rather like our solution for the modules, because i think it's much easier to maintain a shop without having the modules in database. Maybe, our approach and the automatic installer approach are combinable. ___ dev-general mailing
[oxid-dev-general] oxemail: put function calls into property [T-D3898PM6XJ-46]
Hi,
several times we had projects where one of the requirements was to trigger some
special functionality before sending an email from oxemail class. Especially if
this special functionality is dependent on the type of email - it is quite
cumberesome to solve this, cause in the _sendMail() function you do not know
which type of email has to be sent.
So I would like to have a property which is filled by the name of the function
which has been called before, like this:
$_sActMailFunctionCall = ;
public function sendOrderEmailToOwner( $sOrder, $sSubject = null )
{
$this-_sActMailFunctionCall = sendOrderEmailToOwner;
...
}
Of course you could even build a small sort of factory function which would be
called by the several view classes, doing this job - so you would not have to
put a new line of coude into each mail function - like this for example:
in class oxEmail:
public function executeSendMailFunction( $sFunction, $aParams )
{
$this-_sActMailFunctionCall = $sFunction;
$this-$sFunction( $aParams);
}
in oxOrder::_sendOrderByEmail():
$oxEmail-executeSendMailFunction( sendOrderEmailToOwner, $aParams );
Doing this would give developers a whole bunch of nice possibilities. For
example you could write a central function to manipulate email subjects
dependent on the type of email. Or you could save the content of special email
and so on ...
At the moment all this is possible - but you have to overload a lot of
functions for this to detect the type of email.
Using the factory function would mean that the several send-functions would not
have to be changed appart from the parameters given to them. But even this
could be done inside the factory, which then would have to prepare the params
for the single calls.
The factory way in my opinion would be the best one regarding code layout,
but I see that in terms of compatibility to old versions and modules this could
cause some trouble .. - So perhaps as a first step you could just add the first
mentioned line of could to each function?
If somebody has got a better idea to solve this - let me know!
Regards,
Andreas
--
anzido GmbH
Kirchhörder Str. 12
44229 Dortmund
Tel.: 0231 - 60 71 079
Fax.: 0231 - 60 71 081
Mobil:0176 - 8325 1488
Email: i...@anzido.com
Web: http://www.anzido.com ( http://www.anzido.com/ )
USt-ID: DE257982972
Geschäftsführung: Andreas Ziethen
Amtsgericht Dortmund HRB 20883
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Important information about 4.4.1 update [T-AQSJ0TTPGS-10]
Hello, speaking of the updateApp: it would be great if the updateApp would also update the views of the database tables in an OXID eShop EE ;-) If there are changes to the database structure of oxarticles during the update, then you would end up with empty article lists or other problems if you don't update the database views after the update (e.g. in the update to 4.4.0). Beste Grüße aus Dortmund! Robert Rosendahl | Entwicklung u. Support -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 28.07.2010 11:28:04 Von: Arvydas arvydas.vap...@oxid-esales.com An: dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] Important information about 4.4.1 update Vorgang: T-AQSJ0TTPGS-10 Hi, I want to inform, that after analyzing bug #0002003 (https://bugs.oxid-esales.com/view.php?id=2003) we found that updateApp does not execute 28699.sql, so shop version is not updated. If you update your shop using ANY PATCH_OXID_ESHOP_..._TO_V.4.4.1_28950.zip package please execute following query (manually): UPDATE `oxshops` SET `OXVERSION` = '4.4.1'; More information can be found here: http://www.oxid-esales.com/forum/showthread.php?p=36628#post36628 Best regards, Arvydas Vapsva ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
[oxid-dev-general] change oxconfig: allow different config-tables [T-B35QJE6KGT-49]
Hi all, I'd like to discuss an issue that I am thinking about for some time: As a sort of 'best practice' we do try with all our modules to make as few changes as possible to OXID standard-classes, -tables and files (such as lang-files etc.). So if we do need new fields for oxarticle we do prefer to set up an new table and put our stuff in there, connected to the oxarticle table via OXID. Same thing we do with config values. Now, it would be really cool to be able to call methods like getShopConfVar() or setShopConfVar() with an additional parameter containing the table name. So one could just copy oxconfig table and rename it and use that for the own config stuff. Could that be a good idea? Or did I miss anything important? Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Views|public methods [T-L2DDW4THKR-78]
Hi Markus,
this is due to compatibility reasons for old OXID templates which did not use
getters at all.
It will be removed soon ... - I hope! ;-)
There was already a discussion about that stuff here on the list some weeks
ago. Have a look at the digest.
Beste Grüße aus Dortmund!
Andreas Ziethen | Geschäftsführung
--
anzido GmbH
Kirchhörder Str. 12
44229 Dortmund
Tel.: 0231 - 60 71 079
Fax.: 0231 - 60 71 081
Mobil:0176 - 8325 1488
Email: i...@anzido.com
Web: http://www.anzido.com ( http://www.anzido.com/ )
USt-ID: DE257982972
Geschäftsführung: Andreas Ziethen
Amtsgericht Dortmund HRB 20883
-Ursprüngliche Daten-
Datum: 20.05.2010 13:00:47
Von: dasGollum dasgol...@web.de
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] Views|public methods
Vorgang: T-L2DDW4THKR-78
Hi all,
I wondering of some for me useless code in the views.
Eg.:
class Details extends oxUBase
{
public function render()
{
...
$this-_aViewData['aZoomPics'] = $this-getZoomPics();
...
}
}
With this code the pictures can be handle in the template.
But Details::getZoomPics() is public and will be executed in the template,
too.
[{assign var=aZoomPics value=$oView-getZoomPics() }]
In the template return the $this-_aPicGallery array.
So it don't executes twice, just [{$aZoomPic}] filled twice.
But, why this is previous executed in the view itself.
My thinking is, if I make a own Template and don't need zoomPics or whatever.
I don't wanne execute it. If I need it, i execute it in the Template, like
now.
So if the view don't execute public functions, some templates are faster.
This practice is a lot in views and templates.
What you think?
Regards,
Markus
--
Markus Bauer
Paseo del Retiro 3 B
11380 Tarifa/Cadiz
España
N.I.E.: ES-Y0317721-J
Tel./Fax: +34 956682237
eMail: markus.ba...@coyop.de
www: www.coyop.de
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] storage enginges [T-W1V47SNBVS-96]
Hi Sven, yes - that's exactly what we found out, too. But with customers on managed servers it's not always that easy to have those settings changed ... - so before I start blaiming the hosters I'd rather like to know OXID's reasons for switching storage engines before. Cause I suspect that the gain of performance might be that small that a simple back-switch to MyISAM in most cases might be the easier and better way. And for that reason I'd also like to know if there ar any other reasons apart from performance which make InnoDB eg. for oxarticles necessary. Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 11.05.2010 15:47:31 Von: Kliebenstein Sven sven.kliebenst...@burdadigital.de An: dev-general@lists.oxidforge.org dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] storage enginges Vorgang: T-W1V47SNBVS-96 Hi, We have faced the same problem as you mentioned when using InnoDB tables in OXID. If you're using a Not-InnoDB-Optimized-MySQL-Server, the default settings are definitely not usable. The usage of InnoDB tables in an non-optimized MySQL-Server makes things more worse than using standard MyISAM tables. For us, we're always optimizing the settings of your servers before installing the shop. You can get a list of all available InnoDB settings from MySQL by executing this query: show variables like 'innodb%'; The documentation for these options is available from the mysql website: http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html http://dev.mysql.com/doc/refman/5.0/en/innodb-buffer-pool.html There are also some tuning tools available, just have a look for: - tuning-primer - mysqltuner (http://mysqltuner.pl/mysqltuner.pl) Just my 2 cents... Sven -Ursprüngliche Nachricht- Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von anzido GmbH Gesendet: Dienstag, 11. Mai 2010 12:57 An: dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] storage enginges [T-W1V47SNBVS-96] Hi, since a while I notice that OXID does change storage engines for more and more tables from MyISAM to InnoDB. I'd like to get some explanation why this is done, presumably due to performance issues, I guess ... but some more detailed information would be nice. I'd also like to know if and which tables really HAVE to be InnoDB - e. g. for transaction reasons or whatever. The background for my question is that we discover more and more performance problems with those InnoDB tables cause many hosters do use MyISAM optimized MySQL-Settings which often lead to big problems on large InnoDB tables. ProfiHost for example is one of those. Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Deletingunregistereduser acc ounts [T-3CKCXFBU7D-56]
Hi Achim, most shop owners do want to have the user data in their shops to use them for marketing activities and evaluation. They do want to know if somebody is a NEW customer or if he already bought something in the shop etc. All those activities might not be allowed if somebody buys explicitly WITHOUT andy registration. The data have to be kept for fulfillment reasons - but only as long as needed. So from a customer point of view I would agree that data have to be deleted after a certain period of time - which probalby has to be configurable cause there might be some different periods of warranty etc. which have effect on how long the data have to be kept. Another question is, if those data have to be kept in the shop database. I think there might be customers who are (by pretty good reasons!) afraid that their personal data might not be very save on a web server in the internet. From a shop owners point of view (and from the experience with our customers) you probably should keep the data in the shop and make sure that they stay connected with orders, newsletter data and so on. Cheers! Andreas Ziethen | Geschäftsführung Hi, I'd like to know where people see the legal issues with keeping the fulfillment data in the database, be it under oxuser or oxorder. IMO this has nothing at all to do with the advertisement buy without opening an account. Opening an account is nothing more than being able to login later and have all personal data available after logging in. Not wishing to open this account does not legally bind the seller to not store the details, in fact, this being a mailorder business case, data have to be stored. So I think this discussion is beside the point, but please explain otherwise if I'm wrong. Best, Achim (oxal) -Ursprüngliche Nachricht- Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org]im Auftrag von Ralf Trapp Gesendet: Donnerstag, 15. April 2010 16:55 An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] Deletingunregistereduser accounts[T-3CKCXFBU7D-56] Ahoi, I summarize. You basically suggest a procedure like this: 1. During order processing, a temporary account is Created in a 'good' place (what exactly 'good' means is still to be defined). 2. All necessary information for fulfilling the order collected and stored somewhere in a 'good' place (what exactly 'good' means is still to be defined). 3. Previously created temporary account is deleted, order information is kept. I'm not yet talking about database and issues, just want to agree about basic procedure and later on about how to realize it. Regards, Ralf -Ursprüngliche Nachricht- Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von apprent...@gmx.de Gesendet: Mittwoch, 14. April 2010 12:40 An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] Deleting unregistereduser accounts[T-3CKCXFBU7D-56] I think there is(!) a legal problem.. When the order process starts, the guest account is advertised like buy without a customer account in our shop. But matter-of-factly, the shop is allocating a customer account, and it is keeping it forever... So you are basically cheating your customers... Imo xtCommerce handles this situation correctly: During order processing, a temporary account is created, which is deleted after successful order processing. All necessary information for fulfilling the order is kept in the order record(s) in the DB, and this particular order is never changed by the shop any more, if not the shop-owner changes it on purpose (address-info, articles aso.). If the same client should order again later on, new order record(s) will be created. Doing it that way, you both adhere to your promise (no customer account in the shop), and you can fulfill the order. Dipl.-Ing.(TH) Winfried Kaiser (aka Avenger) -Ursprüngliche Nachricht- Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Ralf Trapp Gesendet: Mittwoch, 14. April 2010 12:21 An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] Deleting unregistered user accounts[T-3CKCXFBU7D-56] Hi all, from legal point of view there's no prob at all as of course shop owners need this data to fulfill the order. As changes here affect many (esp. external) connections to and with OXID eShop, I'd like to trigger a discussion about possible _solutions_ which can and should be implemented. Any ideas? Regards, Ralf -Ursprüngliche Nachricht- Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von anzido GmbH Gesendet: Freitag, 13. November 2009 09:13 An: dev-general@lists.oxidforge.org Betreff
Re: [oxid-dev-general] admin links changes in 4.3.0 [T-X2LBL9JQVN-96]
Hi,
this thing made me crazy yesterday evening ...
Therefore some wishes for future versions:
- OXID Developers should on all changes keep in mind if third party modules may
be affected. If so, please annouce such changes as early as possible here in
the list. This would probably avoid a lot of pain for third party developers.
;-)
- Perhaps it would be a good idea to publish a detailed change history for
partners one or two weeks BEFORE the release, so we could check our modules
already.
- On each - at least major - update there should be a clear hint that if third
party modules are used one should check compatibility BEFORE updating the shop.
For us as developers this is self-evident, but for many shop owners it is
obviously not. This morning we did already get some complains about not working
modules after updating to 4.3.
Cheers - and happy Easter Days! :-)
Andreas
--
anzido GmbH
Kirchhörder Str. 12
44229 Dortmund
Tel.: 0231 - 60 71 079
Fax.: 0231 - 60 71 081
Mobil:0176 - 8325 1488
Email: i...@anzido.com
Web: http://www.anzido.com ( http://www.anzido.com/ )
USt-ID: DE257982972
Geschäftsführung: Andreas Ziethen
Amtsgericht Dortmund HRB 20883
-Ursprüngliche Daten-
Datum: 01.04.2010 09:07:29
Von: arunas Valakevicius sarunas.valaskevic...@oxid-esales.com
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] admin links changes in 4.3.0
Vorgang: T-X2LBL9JQVN-96
Hi everybody,
in the new eShop version 4.3.0, the internal links in admin tool are changed
from [{$shop-selflink}]?[{ $editurl }] to [{$shop-selflink}][{ $editurl }].
This allows to add parameters to the selflink not only in templates, but also
in
the admin php classes.
Also, this may affect some modules, which uses admin interface templates with
custom
[{$shop-selflink}]?[{ $editurl }] urls for e.g. frameset definitions. The
'?' character
in these urls should be replaced by the ''.
Regards,
arunas Valakevicius
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Orders with wrong user id [T-VQMIXUCFGV-34]
Hi, actually what the shop does according the user account is mainly correct. And it shouldn't be a problem with orders if the user information stored in oxorder table was used and not the user object based on the oxuserid. Orders should be related to the user by using the email-address instead of oxuserid. Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Ursprüngliche Daten- Datum: 19.03.2010 14:50:54 Von: Reinhard Schneidewind mailing_li...@bluevisiontec.com An: dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] Orders with wrong user id Vorgang: T-VQMIXUCFGV-34 Hi, in OXID 4.2.0 EE we got problems with orders containing wrong user id. After debugging I found out that the problem is a regeneration of the user id after the user data gets updated. Basically the problem is when an unregistered user orders an article and a few minutes later he orders another article with the same user data. In this case the userdata in oxuser gets updated, because the user used the same data the only thing which gets updated is the field `oxuser.OXID`. Now the problem is that the field `oxorder.OXUSERID` from previous order contains the old id from the user which does not exist anymore. Can anyone confirm this? I did not find anything about this in bug tracker. Regards, Reinhard Schneidewind ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Proposal: use spl_autoload_register() instead of__autoload() to allow other autoload functions in OXID [T-2D5PVCNIJK-68]
I agree with that.
It would be nice for example to have own core-, view- and admin-classes in
subfolders inside of modules. Because this does make it very easy to define
project configurations for Zend Guard and other stuff (deployment).
Beste Grüße aus Dortmund!
Andreas Ziethen | Geschäftsführung
--
anzido GmbH
Kirchhörder Str. 12
44229 Dortmund
Tel.: 0231 - 60 71 079
Fax.: 0231 - 60 71 081
Mobil:0176 - 8325 1488
Email: i...@anzido.com
Web: http://www.anzido.com ( http://www.anzido.com/ )
USt-ID: DE257982972
Geschäftsführung: Andreas Ziethen
Amtsgericht Dortmund HRB 20883
-Ursprüngliche Daten-
Datum: 05.03.2010 11:26:42
Von: Stefan Moises moi...@shoptimax.de
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] Proposal: use spl_autoload_register() instead
of__autoload() to allow other autoload functions in OXID
Vorgang: T-2D5PVCNIJK-68
Hi List,
I'd like to make a proposal:
OXID defines its own __autoload() function in core/oxfunctions.php,
which makes it hard to add external libraries containing their own
autoloaders or to implement different autoloaders for own classes/libs.
A solution would be to rename that function to e.g. oxidAutoload() and
to add it to the PHP autoloader stack with
*spl_autoload_register('**oxidAutoload');*
So other autoload functions could be added in the same way, too.
What do you think?
Cheers,
Stefan Moises
--
***
Stefan Moises
Senior Softwareentwickler
shoptimax GmbH
Guntherstraße 45 a
90461 Nürnberg
Amtsgericht Nürnberg HRB 21703
GF Friedrich Schreieck
Tel.: 0911/25566-25
Fax: 0911/25566-29
moi...@shoptimax.de
http://www.shoptimax.de
***
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Feedbackwanted:Keep suppor tforoldertemplating system? [T-0E90ZOGEP6-43 ]
Hi Sven, @Andreas: I'm a little confused about our statement, I remember that we talked about the effort of fixing the old templates and you told me that you've done this in some hours...maybe I've misunderstood you at that time :-0 I think this must have been very close to the release-date of the 4, wasn't it? Cause at the very beginning we tried this with two projects and THOUGHT it was that easy ... - but finally we realized that there were much more places where refactoring was needed to make the old templates fully work. And the other argument was, that after some weeks we also realized that all the new SEO-stuff in the new OXID 4 templates was quite important to improve SEO performace for our customers. And on a long term mainly these two arguments had been responsible for our decision to not longer refactor old tpl's. Additionally I would like to place Andreas' interesting question here again: - Can OXID provide a list of functions and files were the old template support codes resides in? Well, I'm waiting for this, too. Please put some work into this cause it might let us get rid of this issue very soon. Regards! Andreas ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
[oxid-dev-general] orders without orderdate and articles - ipayment-paypal-problem? [T-5BHIZVR86J-77]
Hi all, I could write this to the forum but at this point I do not want to make shop-owners too nervous about the following: (I would have written it to the new partner forum if I would have rights to see it ...) At the moment we have several cases of orders in EE 2.7 shops where we do have no orderdate (it's: -00-00) and no articles for the order. All these orders have in common that they have been done via ipayment credit card payment. And all shops where we do notice this have in common that they do use ipayment AND (efire-)paypal. So I'd like to get some feedback of other partners/developers if you also might notice such cases. You can easily check this out by using the phpMyAdmin, showing table oxorder and sorting it by oxorderdate. If you get orders with orderdate -00-00 00:00:00 then check if they are ipayment orders (have an oxtransid) and if they have articles. @OXID Has this been noticed before? Is there perhaps any knowledge around what's happening here? Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] orders without orderdate and articles-ipayment-paypal-problem? [T-5BHIZVR86J-77]
Hi Michael, I think this is a different problem. An increasing amount of 5002 ipayment errors (wrong card number) is noticed here as well in some shops. But I think this has nothing to do with the problem I mentioned. But that's just a guess - I don't really know. Cheers! Andreas Ziethen | Geschäftsführung -Original data- Date: 27.01.2010 13:06:06 From: Michael Fritsch michael.frit...@print-id.de To: dev-general@lists.oxidforge.org Subject: Re: [oxid-dev-general] orders without orderdate and articles-ipayment-paypal-problem? Task: T-5BHIZVR86J-77 Hi all, I don`t think that this only occurs when using ipayment together with PayPal or there is more than one problem. We have several ipayment orders with error code 5002 and 3001 without using PayPal! Ipayment error 3001 is explained with The amount is incorrect. According to ipayment support in this cases the order amount has been transmitted without a value to their system. Regards Michael -Ursprüngliche Nachricht- Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von anzido GmbH Gesendet: Mittwoch, 27. Januar 2010 12:50 An: dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] orders without orderdate and articles -ipayment-paypal-problem? [T-5BHIZVR86J-77] Hi all, I could write this to the forum but at this point I do not want to make shop-owners too nervous about the following: (I would have written it to the new partner forum if I would have rights to see it ...) At the moment we have several cases of orders in EE 2.7 shops where we do have no orderdate (it's: -00-00) and no articles for the order. All these orders have in common that they have been done via ipayment credit card payment. And all shops where we do notice this have in common that they do use ipayment AND (efire-)paypal. So I'd like to get some feedback of other partners/developers if you also might notice such cases. You can easily check this out by using the phpMyAdmin, showing table oxorder and sorting it by oxorderdate. If you get orders with orderdate -00-00 00:00:00 then check if they are ipayment orders (have an oxtransid) and if they have articles. @OXID Has this been noticed before? Is there perhaps any knowledge around what's happening here? Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] orders without orderdate and articles-ipayment-paypal-problem? [T-5BHIZVR86J-77]
Since I have the rights to visit our new partner forum now - I started a thread about the ipayment problem there and suggest to continue the discussion here: http://www.oxid-esales.com/forum/showthread.php?p=23560 Cheers! Andreas Ziethen | Geschäftsführung -Original data- Date: 27.01.2010 13:06:06 From: Michael Fritsch michael.frit...@print-id.de To: dev-general@lists.oxidforge.org Subject: Re: [oxid-dev-general] orders without orderdate and articles-ipayment-paypal-problem? Task: T-5BHIZVR86J-77 Hi all, I don`t think that this only occurs when using ipayment together with PayPal or there is more than one problem. We have several ipayment orders with error code 5002 and 3001 without using PayPal! Ipayment error 3001 is explained with The amount is incorrect. According to ipayment support in this cases the order amount has been transmitted without a value to their system. Regards Michael -Ursprüngliche Nachricht- Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von anzido GmbH Gesendet: Mittwoch, 27. Januar 2010 12:50 An: dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] orders without orderdate and articles -ipayment-paypal-problem? [T-5BHIZVR86J-77] Hi all, I could write this to the forum but at this point I do not want to make shop-owners too nervous about the following: (I would have written it to the new partner forum if I would have rights to see it ...) At the moment we have several cases of orders in EE 2.7 shops where we do have no orderdate (it's: -00-00) and no articles for the order. All these orders have in common that they have been done via ipayment credit card payment. And all shops where we do notice this have in common that they do use ipayment AND (efire-)paypal. So I'd like to get some feedback of other partners/developers if you also might notice such cases. You can easily check this out by using the phpMyAdmin, showing table oxorder and sorting it by oxorderdate. If you get orders with orderdate -00-00 00:00:00 then check if they are ipayment orders (have an oxtransid) and if they have articles. @OXID Has this been noticed before? Is there perhaps any knowledge around what's happening here? Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Feedbackwanted:Keep suppor tforoldertemplating system? [T-0E90ZOGEP6-43 ]
Hi all, as I said: I'd like to have that stuff removed soon. In many places it's eating up performance unnecessarily. And a 15 months period of having those deprecated values is enough. (They had been marked as deprecated from the very beginning ...) @Sven: Did you really check the amount of time you would need to update those old templates? Actually I cannot really understand why you took this way .. - cause in the very beginning of OXID 4 we tried to take the old templates twice ... - seeing that it did not work to just adopt the old ones but much work had to be done to make for example the order process work. So we decided never to take the old tmeplates cause the effort to switch to the new style was not much bigger as to fix the old templates. The idea to prepare some modules for keeping the old stuff is a good one, I think. @Erik: As you want to remove the old stuff you should know what exactly would have to be removed. So could you perhaps give us a list of files and functions which would be changed due to that? This would make it possible to a. check if all that stuff could be managed by some modules b. devide the task between some more developers and perhaps everybody of this list could contribute ONE module - and we would be done very quickly. :-) Regards! Andreas -Original data- Date: 24.01.2010 23:21:56 From: Erik Kort erik.k...@oxid-esales.com To: dev-general@lists.oxidforge.org Subject: Re: [oxid-dev-general] Feedbackwanted:Keep supportforoldertemplating system? Task: T-0E90ZOGEP6-43 Hi Sven, It's exactly why we asked this in this mailing list. We want feedback. We want the dialog. This is not an decision to be taken lightly. Yes, OXID wants to get rid of this support as its time consuming in maintaining. Maybe we should view this in context of years. The 4.0 was released in October 2008. It's now 2010. We are not talking about removing it next week :) How long do you think is an appropriate time for support? 2011 ? And when will it be acceptable for the client that it's no longer supported ? Did you investigated how much work it is to convert these templates into the new standard? I guess it's costing OXID way more effort in keeping this feature than for this customer in porting the templates. To be honest, I don't think it's fair either to expect indefinite support so that I as customer never need to change anything, waiting until there is a business need like a need the look feel of the shop. The question is: what's a reasonable timeframe for supporting it, reasonable for the whole community. Remember that every time spend in supporting old stuff, is reducing the time to make new cool features. What do you rather have ? I agree, you can't leave clients out in the rain. But if most are already ported, how long do we keep supporting this? indirectly on costs of other clients ... They get a tiny bit of less features .. What is the good timing for stopping support for an old feature? Not an easy answer... BTW Your example scenario EE vs CE is skewed. You still need to update every CE for bugfixes / security fixes reasons. And if that newer version doesn't support the old templates you have the same problem again. So what's the point in this scenario? It doesn't solve your problem. Or do you want to say that this customer is willing to forgo on bug / security fixes just to save template issues ? Now that's a scary thought. Maybe he does have a budget for that ? The idea of an old templating system as a module is very interesting. If we make one, are you willing to maintain it ? This is actually an serious question ;) If anymore of you out there are using old templates. Pls tell us about it here. We want to know.. Regards Erik -Ursprüngliche Nachricht- Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Kliebenstein Sven Gesendet: Donnerstag, 21. Januar 2010 13:16 An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] Feedback wanted:Keep supportforoldertemplating system? Hi all, It seems we're the only ones using old templates in OXID 4 - at least inside this mailing list... Some facts: One of our customers runs an OXID EE 4.2.0 Shop with five subshops in it, the shop was migrated from earlier version 2.7.0.3 to generation 4 of the shop. The templates for two shops, which are the main shops in mall, where completely refactored and updated to new template set. So there are three shops in mall that use the old template sets. The problem is, that these shops are smaller shops making only little conversion, so there's no budget for migrating the templates. Conclusion: If we keep the old templates, this would mean that if the support for old templates is removed, we cannot update the software anymore. So the two primary shops cannot take advantage of new
Re: [oxid-dev-general] where are oxremarks generated [T-2D550CDGNS-17]
Hi Kai, unfortunately this is done in oxemail class ... - where it DEFINETLY does not belong to. It should be in oxorder class. But as I said: look into oxemail::sendOrderEmailToOwner() - there you'll find the fitting code. Small hint: Many programms/editors - like Zend Studio e. g. - do have a function for searching in files or directories, including subdirectories. I answered your question just by putting the term oxremak into that type of search in Zend Studio. Sure you can do that by yourself next time. ;-) Beste Grüße aus Dortmund! Andreas Ziethen | Geschäftsführung -- anzido GmbH Kirchhörder Str. 12 44229 Dortmund Tel.: 0231 - 60 71 079 Fax.: 0231 - 60 71 081 Mobil:0176 - 8325 1488 Email: i...@anzido.com Web: http://www.anzido.com ( http://www.anzido.com/ ) USt-ID: DE257982972 Geschäftsführung: Andreas Ziethen Amtsgericht Dortmund HRB 20883 -Original data- Date: 19.01.2010 01:37:24 From: Kai Gazmaga kai.gazm...@vektordesign.de To: dev-general@lists.oxidforge.org Subject: [oxid-dev-general] where are oxremarks generated Task: T-2D550CDGNS-17 Hello, i want to add some custom information to order-remarks, but i do not find the place they are generated at. Could someone give a hint where the oxremark__oxtext-field is generated or derived from for _orders_? Many thanks in advance, SubNet 5F__ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general Virus checked by G Data AntiVirus Version: AVA 19.9676 dated 19.01.2010 Virus news: www.antiviruslab.com ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] extendet core-classes [T-999MFX0K36-26]
Hi Sascha,
of course you can.
This makes sense if only in special situations you need some user object which
is different from the usual one.
If you do need the modified user object always then you should write a module
of oxuser - but probably you know that.
Cheers!
Andreas Ziethen | Geschäftsführung
--
anzido GmbH
Kirchhörder Str. 12
44229 Dortmund
Tel.: 0231 - 60 71 079
Fax.: 0231 - 60 71 081
Mobil:0176 - 8325 1488
Email: i...@anzido.com
Web: http://www.anzido.com ( http://www.anzido.com/ )
USt-ID: DE257982972
Geschäftsführung: Andreas Ziethen
Amtsgericht Dortmund HRB 20883
-Ursprüngliche Daten-
Datum: 1/5/2010 5:27:32 PM
Von: Sascha J. Hauf - DIS h...@d-i-s.de
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] extendet core-classes
Vorgang: T-999MFX0K36-26
Hi all,
can I mean core-classes with other core-classes to extend
or am not so meant that.
example:
file = core/myclass.php
class myclass extends oxUser
{
}
Thanx an best regards,
Sascha
--
Design Internet Systems
Rüderner Str. 63
73733 Esslingen
Tel.: 07 11 / 3 51 18 03
Fax: 07 11 / 3 51 18 04
E-mail: i...@d-i-s.de
Internet: www.d-i-s.de
Professional eCommerce Solutions
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Create new articlelist [T-4C0IHUVM2Z-71]
@Andreas
I opened also a thread in the forum. But not many developers will answer
questions there.
Could you please send the link of your forum thread to: a.ziet...@anzido.com ?
- Thx. (I could not found it there .. - and I'd quite like to give you some
more hints for your problem.)
Cheers.
Andreas
-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Manuel Reiß
Gesendet: Montag, 16. November 2009 11:53
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Create new articlelist [T-4C0IHUVM2Z-71]
Hi Andreas,
don't know :) - I'm new to this list...
but as you can see in my post But even this won't happen, since the parent
(oxList) will return null ;), this sentence also contains a small hint to
oxid developers
1) the return var-name of oxarticlelist's selectString() $oRes doesn't
seem to contain a boolean var regarding naming conventions ;)
2) oxarticlelist's parent (oxlist) method selectString() doesn't return
anything - and since it's called and its value returned in oxarticlelist,
result will always be null
So I hope besides helping out Andreas before, this post might also be of
value during refactoring and cleanup for the dev-team ;)
best regards,
Manuel
manuel.re...@mediaopt.de | www.mediaopt.de
derksen mediaopt gmbh
galvanistrasse 6 | 10587 berlin | +49 (30) 34 09 42-77 fax-66 | ust.-id
de265886017 | geschäftsführer dipl.-ing. philipp derksen | amtsgericht
charlottenburg | hrb 120935 b
-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von anzido GmbH
Gesendet: Montag, 16. November 2009 10:33
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Create new articlelist [T-4C0IHUVM2Z-71]
Sorry guys - but isn't this stuff for the forum more then for the dev-list?
:-o
Regards!
Andreas Ziethen | Geschäftsführung
-Ursprüngliche Daten-
Datum: 11/16/2009 9:45:24 AM
Von: Manuel Reiß manuel.re...@mediaopt.de
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Create new articlelist
Vorgang: T-4C0IHUVM2Z-71
Hi Roland,
as you can see in the comments of oxarticlelist's selectString-method (*
@return bool), the return value would be boolean.
Therefore your expression
$this-_aList = $aList-selectString($sQuery);
will just set $this-_aList to a boolean value. (But even this won't
happen,
since the parent (oxList) will return null ;) )
Therefore, one solution would be: skip this class-member ($this-_aList)
and
just return your object:
$aList = oxNew('oxarticlelist');
$aList-selectString($sQuery);
return $aList;
have a nice week.
manuel.re...@mediaopt.de | www.mediaopt.de
derksen mediaopt gmbh
galvanistrasse 6 | 10587 berlin | +49 (30) 34 09 42-77 fax-66 | ust.-id
de265886017 | geschäftsführer dipl.-ing. philipp derksen | amtsgericht
charlottenburg | hrb 120935 b
-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Roland
Gruber
Gesendet: Samstag, 14. November 2009 02:15
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] Create new articlelist
Hi everybody
I'm trying do create my first extension for oxid. It should be a new view
for the products of the last x days. I just wrote the code below (with
some
help of the community), saved it in the file newestarticles.php and copied
this file to the folder /view/. So if I call now the class newestarticles
with www.myshop.de/index.php?cl=newestarticles, I can see in the
debug-mode,
that the object 'newestarticles' has been created, but it has no value
(null). Of course, the query SELECT * FROM oxarticles LIMIT 10 gets the
values, which I'd like to have in 'newestarticles'.
Can anybody give me a hint, what I have to change to get the values out of
the query into 'newestarticles'?
Kind regards
Roland
?php
class newestarticles extends oxUBase {
public function init()
{
parent::init();
$this-_sThisTemplate =
'newestarticles.tpl';
}
public function render()
{
$this-_aViewData['newestarticles'] = $this-getnewarticles();
parent::render();
return $this-_sThisTemplate;
}
public function getnewarticles()
{
$sQuery = SELECT * FROM oxarticles LIMIT
10;
$aList = oxNew
Re: [oxid-dev-general] Question about SQL and/or oxBase [T-0E7FRRATQY-89]
I absolutely agree with that. Cheers! Andreas Hello List, one general question about usage of SQL or oxBase Objects. When you have a look at the protected function _setOrderStatus( $sStatus ) in oxOrder a question arises: Why direct SQL and not $this-oxorder__oxtransstatus-setValue(OK); $this-save(); Would be much cleaner then using SQL here, or? Problem that arises from using sql: in the oxorder object the oxtransstatus is still ERROR, so when u save the order object later (e.g. after finalizeorder in a module) the OK status is replaced by ERROR again - Inconsistence comments? Bye Mathias = 5F__ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
