AW: Database utf8 and latin1 questions

2017-01-18 Thread Frank Zunderer 
Hi Gregor,


be careful when using this script, it has a bug that causes your theme and 
module settings to disappear: https://bugs.oxid-esales.com/view.php?id=6012


Frank




Von: gregor.pa...@printus.de 
Gesendet: Mittwoch, 18. Januar 2017 15:57
An: dev-general@lists.oxidforge.org
Betreff: AW: Database utf8 and latin1 questions

Hi both of you,

thanks for the information and explanation. Now I understand your thoughts 
about the migration to utf8. It's fine for me just wanted some background 
information J

Best regards
Gregor Panek
Softwareentwickler
Marketing/E-Commerce
__
Printus GmbH
Carl-Zeiss-Strasse 1, D - 77656 Offenburg
Phone: +49 781 607-498, Fax: +49 781 607-265
gregor.pa...@printus.de
www.printus.de

Printus - Der Film: Werfen Sie einen Blick hinter die Kulissen von Printus: 
www.printus.de/film
Besuchen Sie uns bei Facebook: www.facebook.com/PrintusGmbH


Von: Tomas Kvietkauskas [mailto:tomas.kvietkaus...@nfq.com]
Gesendet: Mittwoch, 18. Januar 2017 14:53
An: dev-general@lists.oxidforge.org
Betreff: Re: Database utf8 and latin1 questions

Hello,

I think this is more related to memory size, latin is a single byte encoding 
while utf8 is two byte encoding (any sysadmin/db admin there correct me if I am 
wrong?)
The other thing that you should keep all ids the same latin encoding to prevent 
type conversion on mysql queries/joins.


-
Tomas


On 18 Jan 2017, at 15:40, Gregor Hyneck 
> wrote:


Hi Gregor

only the columns which are supposed to have utf8 content are changed. We saw no 
benefit to do this for the id columns. If we would change the id columns, there 
could be problems with 3rd party systems or more effort to update an existing 
database. But you are right, this behavior is a little bit inconsistent and you 
have to keep it in mind.

Kind regards
Gregor Hyneck
Software Developer
OXID eSales AG
Bertoldstraße 48
79098 Freiburg
Deutschland

Vorstand: Roland Fesenmayr (Vorsitzender)
Vorsitzender des Aufsichtsrats: Michael Schlenk, Sitz: Freiburg
Amtsgericht Freiburg i. Br., HRB 701648, USt-IdNr.: DE231450866

Am 18.01.2017 um 13:15 schrieb 
gregor.pa...@printus.de:
Hi all,

I'm currently changing our database to utf-8 with the provided OXID script from 
this 
page:https://www.oxid-esales.com/en/support-services/documentation-and-help/oxid-eshop/installation/oxid-eshop-update-installation/update-eshop-to-utf-8-encoding.html
Now I'm still wondering why we change everything to utf8 except the ID Columns 
which are still latin1 encoded? What's the reason behind this? Can someone 
explain this? In my opinion this is a little bit inconsistent and generates 
additional work when creating new tables because you have to keep in mind to 
set the encoding for the ID Columns as latin1.


Best regards
Gregor Panek
Softwareentwickler
Marketing/E-Commerce
__
Printus GmbH
Carl-Zeiss-Strasse 1, D - 77656 Offenburg
Phone: +49 781 607-498, Fax: +49 781 607-265
gregor.pa...@printus.de
www.printus.de

Printus - Der Film: Werfen Sie einen Blick hinter die Kulissen von Printus: 
www.printus.de/film
Besuchen Sie uns bei Facebook: www.facebook.com/PrintusGmbH

Re: [oxid-dev-general] Can't remove old module entries

2016-03-30 Thread Frank Zunderer 
Hi Alexander,

 

Module config is also cached in /tmp

 

Greets,

Frank

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Alexander
Scheider
Gesendet: Mittwoch, 30. März 2016 13:21
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Can't remove old module entries

 

Hello Alexander,

 

thank you for your answer.

the ffb/metadata.php file does not exists anymore. It is old module which is
was removed on shop update.

The old module had no invalid entries and worked pretty well with OXID EE
4.6.3

The metadata of old module contains classes which can’t be removed:

'oxutilsfile' => 'ffb/core/ffb_oxutilsfile',

'oxutilspic'  => 'ffb/core/ffb_oxutilspic',

'oxuserbasket'=>  'ffb/core/ffb_oxuserbasket'

 

I don’t know, maybe is there any another database table except oxconfig
which contains module entries.

I mean after removing of aModules from oxconfig, where can those broken
entries be stored?

 

Kind regards,

Alexander Scheider

 

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Alex Schwarz
Gesendet: Mittwoch, 30. März 2016 13:09
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Can't remove old module entries

 

Hi Alexander,

did you check the ffb/metadata.php for invalid entries? There could be an
old/invalid entry, maybe you reference a file there that does no longer
exists?

If you are using PHPStorm with the OXID Plugin enabled, you will have syntax
support for metadata.php!

Best regards

-- 

Alexander Schwarz
Senior Web Developer




active value GmbH
Benzenbergstraße 39-47
40219 Düsseldorf

Telefon: +49 (0)211-749 505 15
Telefax: +49 (0)211 749 505 99

E-Mail:   alex.schw...@active-value.de
Internet: www.active-value.de

HRB 55441, Amtsgericht Düsseldorf
Geschäftsführer: Antonius Klees, Alexander Pisculla

P Please consider the environment before printing this email







  Alexander Scheider

30. März 2016 um 13:03

Hi folks,

 

I’m using OXID EE 5.2.7 and  have a problem with old module entries which
can’t be deleted in OXID backend or database.

Every time by clicking on Extensions -> Modules i get following list:

 



 

After click on yes i see the list with all installed modules, but if i enter
the modules next time,  the dialog appears again.

I have got already tried to reset the modules from oxconfig with

UPDATE `oxconfig` SET `OXVARVALUE` =
0x4dba322c774f5444a5777125d61918a96e9e65e1b8fba2e9f6f8ff4e240b745241e4b01edd
9224c81f3020f58a2d WHERE `OXVARNAME` = 'aModules'

 

Or to remove all informations with:

delete from oxconfig where oxvarname in (

'aDisabledModules',

'aLegacyModules',

'aModuleFiles',

'aModulePaths',

'aModules',

'aModuleTemplates'

);

 

I also tried to export config with
https://github.com/druteika/oxid_modules_config module.

In every extend of all modules i have those old entries:

"oxutilsfile": "ffb\/core\/ffb_oxutilsfile",

 "oxutilspic": "ffb\/core\/ffb_oxutilspic",

 "oxuserbasket": "ffb\/core\/ffb_oxuserbasket"

 

Modification of json-file and reimport of configuration didn't helped. After
import of the configuration, open Extensions  -> Modules and export of
config again, the entries are added again to the extend array.

 

OXID-Console command had also no luck: php oxid fix:states –all

 

Does anyone have any advice how to fix this problem.

 

 

Kind regards,

Alexander Scheider

 

___
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] New blog post on planet: Overloading non-overloadable classes - don't!

2015-10-13 Thread Frank Zunderer IT Beratung 
Hello all,

i would suggest to label oxshopcontrol "can be overloaded but oxwidgetcontrol 
extends it" like alist/details. Also i suggest to refactor oxwidgetcontrol into 
oxshopcontrol so it can be fully extended again. Are there any objections 
against this?

Regards,
Frank Zunderer



-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Marco 
Steinhaeuser
Gesendet: Mittwoch, 26. August 2015 14:11
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] New blog post on planet: Overloading 
non-overloadable classes - don't!

Hey folks,

did you use oxShopControl in modules yet? Well, it was moved to 
non-overloadable classes recently. Please read this blog post to find a 
workaround. All others: hands off these classes 
http://planet.oxidforge.org/2015/08/overloading-non-overloadable-classes-dont.html

Cheers
Marco
___
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] Mysterious error: Call to a member function pageClose() on a non-object

2014-07-15 Thread Frank Zunderer 
Hi All,

 

oxconfig::init() is only called in oxconfig::getConfigParam, which looks a
bit arbitrary. If you don't use getConfigParam, oxconfig is not initialized.
For example this code:

 

require_once dirname(__FILE__) . /../bootstrap.php;

 

// initializes singleton config class

$myConfig = oxRegistry::getConfig();

 

/*Commented out to stop maintenance temporarily*/

// executing maintenance tasks.. 

//oxNew( oxmaintenance )-execute();

 

// closing page, writing cache and so on..

$myConfig-pageClose();

 

In bin/cron.php will trigger this error onscreen.

 

I think oxconfig could be initialized in oxregistry::getConfig

 

Regards,

Frank Zunderer

 

Zunderer IT Beratung

Waldstr. 22

82205 Gilching

 

08105-777250

0173-8362768

it-berat...@zunderer.de

 

 

 

 

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Clemens Sahs
Gesendet: Dienstag, 15. Juli 2014 17:50
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Mysterious error: Call to a member function
pageClose() on a non-object

 

moin Maximilian,

 

On my the first examination you overwrite the original file, the original
line is 650.

https://github.com/OXID-eSales/oxideshop_ce/blob/v4.8.6/source/core/oxconfig
.php#L650

 

In the case that you overwrite important lines, this that can be the source
of you problem.

In the case that you overload the oxconfig::init function with a custom
module you need a parent::init() call

 

 

hope this help you

 

Best regards,

clemens 

 

 

 

Am 15.07.2014 um 17:32 schrieb Maximilian Walter mail...@max-walter.net:





Hello everybody,

I noticed today the following PHP-error in the log-files

[Tue Jul 15 16:03:02 2014] [error] [client x.x.x.x] PHP Fatal error: Call to
a member function pageClose() on a non-object in /path/to/core/oxconfig.php
on line 642, referer: http://example.com/

I can't explain the errors. I'm also not able to reproduce it, although they
appear quite frequently. I checked the access-log and didn't found anything
suspicious, only status-code 200 and no requests to offline.html.

Has anybody experience with an similar problem?

We use OXID Professional Edition 4.8.6 with some custom modules.

Thanks in advance.

Best regards,
Maximilian
___
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] Blocks save path changed in 4.8?

2014-01-21 Thread Frank Zunderer 
Hi,

 

i think it wasn’t changed, it’s still out/blocks if you specify only the
filename, but it can be any folder if you specify with path from module
folder.

 

Regards,

Frank Zunderer

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Alexander
Kludt
Gesendet: Dienstag, 21. Januar 2014 14:33
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] Blocks save path changed in 4.8?

 

Hi guys,

from what I can see the blocks in 4.8 are now stored in 

modules/mymodule/views/blocks

they used to be stored in 

modules/mymodules/out/blocks

why the heck was that changed without any backward compatibility?
Was this mentioned anywhere? Did I miss anything?

-- 

best regards
Alexander Kludt 

__ 
Phone: 09283-5925453 
Fax: 09283-592671 
Skype: kingschnulli 
Email: cod...@aggrosoft.de 
Website: www.aggrosoft.de 

__ 
Aggrosoft it intelligence GbR 
Tannstrasse 12 
95111 Rehau 
GERMANY 

Sitz Rehau, Amtsgericht Hof 
Steuernummer: 223/165/54508 
Ust.-Id. Nr. gemäß § 27 a Umsatzsteuergesetz: DE260722773 

___ 
Diese Nachricht ist nur für den Empfänger bestimmt, sollten 
Sie nicht der Empfänger sein löschen Sie diese Nachricht 
umgehend und geben Sie uns bitte per Email (cod...@aggrosoft.de) Bescheid 
über den fälschlichen Erhalt.  

___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Extending mobile Theme with modules

2013-11-25 Thread Frank Zunderer 
Hi Linas,

thank you, this sounds good, i would suggest to add this to standard, a
method that returns false in shop's oxviewconfig and this method in
themeswitcher's oxviewconfig, and change paypal module so it makes use of
this method instead of changing block names in mobile theme, so programmers
could take paypal module as an example for integration.

Regards Frank




-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Linas
Kukulskis
Gesendet: Montag, 25. November 2013 13:54
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Extending mobile Theme with modules

Hi, Frank

If i correctly understood, you want to write a module which extends
templates (add changes) and is suitable for both mobile and desktop theme.
You do not want add new block to mobile theme and it should not depend, how
the mobile theme is named.

So in general there are no problem to do that: you can define  which block
you extend in metadata file (as usual in desktop theme). The problem occurs,
when extended block should look differently (or have different
functionality) in mobile theme than in desktop. In this case you can follow
suggestion in documentation, but it need new blocks. There is also another
way. What you need is in your block add check if its mobile theme or
desktop, and proceed different action for example:

[{if  check for mobile theme }]

// do something for mobile

[{else}]

// do something for desktop

[{/if}]

oeThemeSwitcherThemeManager class provides functionality that your can get
the active theme type (mobile or desktop):
oeThemeSwitcherThemeManager::getThemeType(),
oeThemeSwitcherThemeManager::isMobileThemeRequested(). Using these methods
you can add functionality for check in your controllers or oxViewConfig and
use in blocks. Do not  forget ensure that shop has theme switcher activated.
The code can be something like this:

public function isThemeMobile(){
$blIsMobile = false
if ( !class_exists('oeThemeSwitcherThemeManager')) {
$oThemeManager = new oeThemeSwitcherThemeManager();
$blIsMobile = $oThemeManager-isMobileThemeRequested();
}
return $blIsMobile;
}


 

Linas Kukulskis
Developer

linas.kukuls...@oxid-esales.com
Phone +370 37 333053
Fax +370 37 333054
www.oxid-esales.com





From: dev-general-boun...@lists.oxidforge.org
[dev-general-boun...@lists.oxidforge.org] on behalf of Frank Zunderer
[frank.zunde...@zunderer.de]
Sent: Thursday, November 14, 2013 6:53 PM
To: dev-general@lists.oxidforge.org
Subject: Re: [oxid-dev-general] Extending mobile Theme with modules

Hi Linas,

thanks for the response. I also filed a bug for this topic:
https://bugs.oxid-esales.com/view.php?id=5517

Regards,
Frank

-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Linas
Kukulskis
Gesendet: Donnerstag, 14. November 2013 17:21
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Extending mobile Theme with modules

Hi,

Thanks Frank, good point - we'll have a meeting about it on Monday and let
you know about the results as soon as possible

Linas Kukulskis
Developer

linas.kukuls...@oxid-esales.com
Phone +370 37 333053
Fax +370 37 333054
www.oxid-esales.com





From: dev-general-boun...@lists.oxidforge.org
[dev-general-boun...@lists.oxidforge.org] on behalf of Frank Zunderer
[frank.zunde...@zunderer.de]
Sent: Tuesday, November 12, 2013 2:11 PM
To: dev-general@lists.oxidforge.org
Subject: [oxid-dev-general] Extending mobile Theme with modules

Hello All,

i just had a look into extending a module for usage in the mobile theme, and
somehow I cannot find a way to manage this. It seems quite impossible to me
to write a module that just installs and works for mobile and desktop.

I read the section in documentation Adding complete module support for
mobile:

Due to changes to template files in the mobile theme, some modules might
not work with a mobile theme from the get-go. However it is possible to get
modules working for the theme without needing to patch or alter the module.
You can add specific blocks for modules in a theme switcher, which allows
for module developers to have different module looks on mobile devices. With
this, you don't need to make additional patches for the module itself, when
it can be added to module switcher.

This might be useful for the Shop-Owner, the module developer does not want
to change the theme switcher, but have all changes in the module itself.

To have an example of how to make a module look differently on mobile
devices, look at PayPal implementation. For any shops using the PayPal
module, the new mobile theme switcher has changes for PayPal, insuring that
module works as well as it does in the desktop theme. Edit the mobile theme
switcher metadata.php

Re: [oxid-dev-general] Extending mobile Theme with modules

2013-11-14 Thread Frank Zunderer 
Hi Linas,

thanks for the response. I also filed a bug for this topic:
https://bugs.oxid-esales.com/view.php?id=5517

Regards,
Frank

-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Linas
Kukulskis
Gesendet: Donnerstag, 14. November 2013 17:21
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Extending mobile Theme with modules

Hi,

Thanks Frank, good point - we'll have a meeting about it on Monday and let
you know about the results as soon as possible

Linas Kukulskis
Developer

linas.kukuls...@oxid-esales.com
Phone +370 37 333053
Fax +370 37 333054
www.oxid-esales.com





From: dev-general-boun...@lists.oxidforge.org
[dev-general-boun...@lists.oxidforge.org] on behalf of Frank Zunderer
[frank.zunde...@zunderer.de]
Sent: Tuesday, November 12, 2013 2:11 PM
To: dev-general@lists.oxidforge.org
Subject: [oxid-dev-general] Extending mobile Theme with modules

Hello All,

i just had a look into extending a module for usage in the mobile theme, and
somehow I cannot find a way to manage this. It seems quite impossible to me
to write a module that just installs and works for mobile and desktop.

I read the section in documentation Adding complete module support for
mobile:

Due to changes to template files in the mobile theme, some modules might
not work with a mobile theme from the get-go. However it is possible to get
modules working for the theme without needing to patch or alter the module.
You can add specific blocks for modules in a theme switcher, which allows
for module developers to have different module looks on mobile devices. With
this, you don't need to make additional patches for the module itself, when
it can be added to module switcher.

This might be useful for the Shop-Owner, the module developer does not want
to change the theme switcher, but have all changes in the module itself.

To have an example of how to make a module look differently on mobile
devices, look at PayPal implementation. For any shops using the PayPal
module, the new mobile theme switcher has changes for PayPal, insuring that
module works as well as it does in the desktop theme. Edit the mobile theme
switcher metadata.php, located in /modules/oe/oethemeswitcher, override
blocks like this: 'blocks' = array( . array('template' =
'page/checkout/payment.tpl', 'block'='mb_select_payment',
'file'='views/mobile/blocks/oepaypalpaymentselector.tpl'), ), Use mb_
prefix for block name, so it's clear that this block is for mobile.

Paypal-like implementation inside the theme switcher is not an option for
other modules. Even the paypal module seems to leave that road and has the
blocks inside the module itself.

Change the desired blocks (for example select_payment) name to have prefix
mb_ (mb_select_payment) where you want blocks to be replaced in theme
files.

I looked in the template, there are already some blocks prefixed with mb_,
and these are the blocks paypal uses. So if I want to use another block in
my own module, it looks like I'm supposed do the same and edit the theme
files, and this prevents easy installation and might break other modules
that use the blocks without prefix.

Adding desired mobile device functionality in other ways: You can add
different looks and feels for your module in another way. You can use
getActiveThemeId() method to get the active theme, and then add desired
functionality for that.

In theme switcher you have the possibility to enter another theme name in
module options, so one can't rely on the theme id mobile. All in all I
don't see how extending mobile theme with own blocks is possible without
manually changing files.

When I saw you could prefix mobile blocks with mb, at first I thought this
would already be possible for all blocks, maybe this would be a solution to
prepend mb_ to all blocks in mobile theme so they are always different than
the desktop ones, or maybe this could be done by the theme switcher in a
transparent way, so that block base_js would work in desktop and mobile,
but if mb_base_js is additionally specified, this would point to the block
base_js in mobile theme.

Regards,
Frank Zunderer



___
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

[oxid-dev-general] Extending mobile Theme with modules

2013-11-12 Thread Frank Zunderer 
Hello All,

i just had a look into extending a module for usage in the mobile theme, and
somehow I cannot find a way to manage this. It seems quite impossible to me
to write a module that just installs and works for mobile and desktop. 

I read the section in documentation Adding complete module support for
mobile:

Due to changes to template files in the mobile theme, some modules might
not work with a mobile theme from the get-go. However it is possible to get
modules working for the theme without needing to patch or alter the module.
You can add specific blocks for modules in a theme switcher, which allows
for module developers to have different module looks on mobile devices. With
this, you don't need to make additional patches for the module itself, when
it can be added to module switcher.

This might be useful for the Shop-Owner, the module developer does not want
to change the theme switcher, but have all changes in the module itself.

To have an example of how to make a module look differently on mobile
devices, look at PayPal implementation. For any shops using the PayPal
module, the new mobile theme switcher has changes for PayPal, insuring that
module works as well as it does in the desktop theme. Edit the mobile theme
switcher metadata.php, located in /modules/oe/oethemeswitcher, override
blocks like this: 'blocks' = array( . array('template' =
'page/checkout/payment.tpl', 'block'='mb_select_payment',
'file'='views/mobile/blocks/oepaypalpaymentselector.tpl'), ),
Use mb_ prefix for block name, so it's clear that this block is for mobile.

Paypal-like implementation inside the theme switcher is not an option for
other modules. Even the paypal module seems to leave that road and has the
blocks inside the module itself.

Change the desired blocks (for example select_payment) name to have prefix
mb_ (mb_select_payment) where you want blocks to be replaced in theme
files.

I looked in the template, there are already some blocks prefixed with mb_,
and these are the blocks paypal uses. So if I want to use another block in
my own module, it looks like I'm supposed do the same and edit the theme
files, and this prevents easy installation and might break other modules
that use the blocks without prefix.

Adding desired mobile device functionality in other ways: You can add
different looks and feels for your module in another way. You can use
getActiveThemeId() method to get the active theme, and then add desired
functionality for that.

In theme switcher you have the possibility to enter another theme name in
module options, so one can't rely on the theme id mobile. All in all I
don't see how extending mobile theme with own blocks is possible without
manually changing files. 

When I saw you could prefix mobile blocks with mb, at first I thought this
would already be possible for all blocks, maybe this would be a solution to
prepend mb_ to all blocks in mobile theme so they are always different than
the desktop ones, or maybe this could be done by the theme switcher in a
transparent way, so that block base_js would work in desktop and mobile,
but if mb_base_js is additionally specified, this would point to the block
base_js in mobile theme.

Regards,
Frank Zunderer



___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] 4.5.0 Update

2013-10-30 Thread Frank Zunderer 
Hi,

 

there are two places where the version is stored, one is in DB, table oxshops, 
fields OXEDITION (CE,PE,EE) and OXVERSION (e.g. 4.7.8). The other is a file 
called pkg.rev in root directory which contains the revision (e.g. 34568). 
Oxchkversion takes both of them and if they don’t match it’ll give an error, 
because somehow your files version is not the same as your database version. 
Looks like your DB is version 3.0.4.1 and your shop-files are version 4.5.0 
(because 4.5.0 has revision number 34568).

 

Regards,

Frank Zunderer

 

Zunderer IT Beratung

Waldstr. 22

82205 Gilching

 

08105-777250

0173-8362768

it-berat...@zunderer.de

 

 

 

Von: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Mirza Ahtasham 
Ahmad
Gesendet: Mittwoch, 30. Oktober 2013 21:59
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] 4.5.0 Update

 

Hi Marco,



I run the oxchkversion.php script and get the following error.

OXID eShop (unknown) 3.0.4.1 in Revision 34568 does not exist.

Can you tell what that means ??

Thanks and looking forward to your reply.

Mirza





 

 

On Mon, Oct 28, 2013 at 8:45 AM, Marco Steinhaeuser 
marco.steinhaeu...@oxid-esales.com wrote:

Hi,

http://exchange.oxid-esales.com/OXID-oxid-oxid/Additional-OXID-Extensions/Oxchkversion-3-2-1-Stable-CE-4-7-x.html
There also might exist some diff tools for the database structure. 

Best
Marco

  _  

From: dev-general-boun...@lists.oxidforge.org 
[dev-general-boun...@lists.oxidforge.org] on behalf of Mirza Ahtasham Ahmad 
[ahtasha...@gmail.com]

Sent: Monday, October 28, 2013 7:59 AM


To: dev-general@lists.oxidforge.org
Subject: Re: [oxid-dev-general] 4.5.0 Update

 

Hi Marco,

Where can I find oxchkversion and any documentation on how to use the tool?

I really think that the database is in very old version. Can I check somewhere 
database versions/changes corresponding to each OXID Versions??

The problem is only that I don't have these tables in my sb and update script 
from 4.5.0 tries to alter those, thinking they exist.

Mirza



On Oct 28, 2013 12:38 AM, Marco Steinhaeuser 
marco.steinhaeu...@oxid-esales.com wrote:

Mirza,

updating the database only as you come from 4.5.0 to the latest version is 
probably not the worst idea. Use the updateApp.php to achieve that! In case of 
SQL errors like you describe it check the MySQL version you run.
Also - independent from the database - there's the so called oxchkversion to 
check the consistency of your files, before and after the update process.

Regards
Marco

  _  

From: dev-general-boun...@lists.oxidforge.org 
[dev-general-boun...@lists.oxidforge.org] on behalf of Mirza Ahtasham Ahmad 
[ahtasha...@gmail.com]
Sent: Sunday, October 27, 2013 12:51 PM
To: dev-general@lists.oxidforge.org
Subject: Re: [oxid-dev-general] 4.5.0 Update

Hi Guys,

Again...I think the site is not in 4.5.0 Version...when I log into the admin I 
see the follwoing version at the top right corner...

Professional Edition 4.5.0_34568

but once I ran the update package from 

UPDATE_OXID_ESHOP_PE_V.4.5.0_34568_TO_V.4.6.5_49955_for_PHP5.3

It gave me errors on query for the tables like oxconfigdisplay, oxtplblocks, 
oxseo ... theses table aren't present in my db and the script is trying to 
alter those tables...

Then I have a oxconfig table and another oxconfig2 tableso I am thinking 
that the version is updated in the db only but the site is still the old 
one...right ???

What do you guys say ?



Thanks and looking forward to your replies.

Mirza









 

On Sun, Oct 27, 2013 at 12:16 PM, Mirza Ahtasham Ahmad ahtasha...@gmail.com 
wrote:

Hi,

Guys, I want to update my Current OXID 4.5.0 site Database to the latest 
version.

Actually I am thinking of installing a new copy of OXID 4.7.8 and update only 
the database.

For that I saw the steps...that First from 4.5.0 to 4.6.5...then 4.6.5 to 4.7.0 
and then 4.7.0 to 4.7.8.

But I got stuck in the first step, I installed OXID_ESHOP_PE_4.7.8_for_PHP_5.3, 
setup the config file with my old 4.5.0 DB. and now I am getting this error 
when I try to access the homepage...


oxConnectionException-oxException (time: 2013-10-27 11:41:31): [0]: Unable to 
load shop config values from database 
 Stack Trace: #0 C:\wamp\www\oxid478\core\oxutilsobject.php(185): 
oxUtilsObject-_getObject('oxconnectionexc...', 0, Array)
#1 [internal function]: oxUtilsObject-oxNew('oxConnectionExc...')

and when I try to update the db via updateApp and press Start Update button, I 
get the following error.

Shop offline! 

Error: script did not finish successfully.
Please check oxupdatetrack database table for executed actions.

 

Can anybody help me out here...I should be able to partially use the OLD DB 
with the new installation. right ??

Looking forward to your reply guys...





-- 

Mit freundlichen Grüßen, 
Ahmad 

+4917645387460 tel:%2B4917645387460 




-- 

Mit freundlichen Grüßen, 
Ahmad

Re: [oxid-dev-general] Adding params to oxlocator

2013-07-05 Thread Frank Zunderer 
Hi Daniel,

best practice i don't know, but maybe something like the following module
for search could be useful:

?php
class addparam_search extends addparam_search_parent
{
public function getAdditionalParams()
{
$sParams = parent::getAdditionalParams();
return $this-_addSpecialParam( $sParams );
}
protected function _addPageNrParam( $sUrl, $iPage, $iLang = null )
{
$sUrl = parent::_addPageNrParam( $sUrl, $iPage, $iLang );
return $this-_addSpecialParam( $sUrl );
}
protected function _addSpecialParam( $sUrl ){
$sUrl .= amp;test=test;
return ( $sUrl );
}
}

Regards,
Frank Zunderer

Zunderer IT Beratung
Waldstr. 22
82205 Gilching

08105-777250
0173-8362768
it-berat...@zunderer.de




-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Daniel
Schlichtholz
Gesendet: Freitag, 5. Juli 2013 13:49
An: Oxid Dev-List
Betreff: [oxid-dev-general] Adding params to oxlocator

Hi list,

I need to add a param to all actions that are triggered via the locator-bar
on the search result page.
But since each sub part (Pagination, View, Products per page and
Sorting) does build the link target differently, I do break my ass to add a
param that is reflected in all generated link targets.

What is the best practice to do so?

--
Best regards,

Daniel Schlichtholz
Zu den Brauckstücken 5
58313 Herdecke

___
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] Template Changes in Minor Versions

2013-02-06 Thread Frank Zunderer 
Hi all,

while answering a forum post i stumbled across this bug: 
https://bugs.oxid-esales.com/view.php?id=4240

This is not resolved in current version because: as this does require template 
changes, we will release it only in 5.1. For earlier versions please use this 
fix ...

I understand the policy not to do template changes in minor versions, i don’t 
think this is a good policy though. The reason not to change templates is this:
Except for important bug fixes, we usually don’t do any template changes in 
patches. This makes your life much easier when patching an existing OXID eShop.

Well I would think this is an important bug fix as selection lists are not 
usable without it.

Even if not, bugs in Templates are a different story than changing folder 
structure, variable names, method calls etc. No one benefits from not releasing 
bugfixes in Templates. Contrary, this makes life not easier but harder because 
in order to have a fully functional shop you would have to keep track of all 
solved but not yet released template bugs and fix them yourself. I think this 
policy needs to be rethought.

Regards,
Frank Zunderer

___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] OXID Deployment System + The Community

2012-11-23 Thread Frank Zunderer 
Hi Marco,

 

in my opinion OXID could be much more „community driven“ without code
contributions if there was more communication. OXID devs very rarely comment
conceptual suggestions in this list and also in the bugtracker. Before
developing or submitting new code, the concepts behind the new code would
have to be discussed, which is not happening. This leads to the impression
that there is no way to contribute to development process except posting
bugs where documented features do not work the way they are documented, or
Uservoice where new features can be suggested. Both places are not suitable
for suggesting conceptual changes to the code, so you can only wait until
next release to see what the devs have cooked in their private kitchen.

 

Regards Frank

 

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Marco
Steinhaeuser
Gesendet: Freitag, 23. November 2012 12:09
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] OXID Deployment System + The Community

 

Hi guys,

@Dave: thanks for your thoughts. This is close to the way we are thinking
presently. But: no decisions made yet nor any time frame!

Actually, the development and CI structures have been build up before we
went open source. In this time nobody expected any contributions :-)

The re-structure is just a technical issue as well as a question of time and
resources: the code base has to be split, the CI process (grown
historically) has to be re-factored etc...

@Alex:
 this will never ever happen
Never say never.

 but to me this looks like a prevention mechanism so nobody can recreate
enterprise features
Wrong.

 Oxid will end up like osCommerce did.
You could have found a better example ;)

@Marc: You're wrong.


Regards and have a nice weekend
Marco

  _  

From:  mailto:dev-general-boun...@lists.oxidforge.org
dev-general-boun...@lists.oxidforge.org
[dev-general-boun...@lists.oxidforge.org] on behalf of Development @ ORCA
Services AG [developm...@orca.ch]
Sent: Thursday, November 22, 2012 2:24 PM
To:  mailto:dev-general@lists.oxidforge.org
dev-general@lists.oxidforge.org
Cc: Dino Fellmann - ORCA Services AG
Subject: Re: [oxid-dev-general] OXID Deployment System + The Community

Hi Dave

 

Thanks for your thoughts.

To put it simple:

In my opinion OXID eSales, or better said the management of them, never
really understood the concept of a real community driven/developed, open
source software.

What they see is a product to market, a property to protect, just like a
usual piece of proprietary software.

They talk about the OXID eco system, not the community, there we have it.

And thus we will never ever see something just remotely resembling to what
you described if not something in management’s head changes…

 

It’s kind of depressing but that’s the way I, and probably not just me, see
it.

 

Greetings from Switzerland

Marc Würth

 

ORCA Services AG
Bahnhofstrasse 11
CH-4133 Pratteln
Office Basel: Aeschengraben 10, CH-4051 Basel

 

 mailto:marc.wue...@orca.ch marc.wue...@orca.ch
T. +41 61 205 80 80

T. +41 61 205 80 73 (direkt)

F. +41 61 205 80 81


 http://www.orca.ch www.orca.ch,  http://www.orca-services.ch
www.orca-services.ch

 

We convert your visitors into customers.

  _  

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Dave
Holloway
Gesendet: Donnerstag, 22. November 2012 10:19
An:  mailto:dev-general@lists.oxidforge.org
dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] OXID Deployment System + The Community

 

Hi all,

I was having a bit of a surf yesterday and found this comment from Erik:

http://phpterror.wordpress.com/2009/08/26/oxid-esales-show-me-your-94-unit-t
est-coverage/#comment-16

The original post was about unpublished Unit-Tests, which wasn't terribly
interesting, but it was the comment that caught my eye. It describes the
internal code deployment system of OXID and why it's tricky to accept code
contributions. 

It's now clear to me why the switch to a distributed version platform such
as GIT/GITHub/BitBucket is so difficult: OXID has one codebase, and the
deployment scripts remove certain parts for the different distributions (i.e
the SOAP-Code gets removed for PE, and the WYSIWYG-Editor gets removed for
CE etc.). This means it isn't practical or even possible for OXID to share
their code, and why we only have access to the neutered pseudo SVN
repository at http://svn.oxid-esales.com, where almost all authors are
called nightlybuild.

The whole structure got me thinking: why does this problem exist?, and I'm
pretty sure that it all boils down to the marketing of the editions
(CE/PE/EE). Each edition is advertised as a separate product, each with
(basically) a separate license. Since most of the codebase of the 3 editions
are the same, people who want to contribute need to jump through hoops and
sign NDAs/similar documents to agree that the

Re: [oxid-dev-general] Question about Shipping Costs

2012-11-19 Thread Frank Zunderer 
Hello Christoph,

i think the forums would be a better place to get help on specific problems
with configuration of shipping costs.

Regards, Frank


-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Christoph
Daum
Gesendet: Montag, 19. November 2012 14:40
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Question about Shipping Costs

Well... sorry for writing again, but I'm stuck again, after it seemed to
work fine yesterday, it doesn't work now.

I appreciate any ideas.

Greetings


Am 18.11.2012 um 17:49 schrieb Christoph Daum c.d...@apermo.de:

 Hi, already solved it myself. Was a cache problem.
 
 Greetings.
 
 Am 18.11.2012 um 17:39 schrieb Christoph Daum c.d...@apermo.de:
 
 Hello everybody,
 
 I have a problem. I am currently releasing a new oxid shop, and my
customer wants to have the following shipping costs.
 
 1-3 articles of category A - 4,90
 4-11 articles of category A - 5,90
 12+ articles of category A - free of charge
 (All once per cart)
 
 In addition there are articles of category B (some goodies).
 
 If the customer orders only from category B its 2,90 for shipping. In any
other cases these articles are shipped for free, and only the shipping costs
stated above for category A shall be used.
 
 I configured it that the shipping cost rules should only apply to
articles from the corresponding categories, but the problem is that the
amount once per cart includes the products from category B.
 
 Example:
 
 3 articles from Cat A +  1 article from Cat B shall be 4,90. But as the
total amount is 4 it uses the rule for 4-11 articles - 5,90.
 
 Does anyone have an idea for this?
 
 Thanks in advance.
 
 Christoph Daum
 ___
 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

___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Release candidate 1 for OXID eShop version 4.7/5.0

2012-10-12 Thread Frank Zunderer 
Hi All,

 

i already stated that i really like the new folder structure. 

 

But I agree with Joscha, I hope the templates will move back to /out in the
final version. This makes things more complicated while giving no real
benefit. On the one hand there are efforts to keep all module files inside
the module folder for easy handling and distribution, now on the other hand
with templates you tear the template folder, which should be one unit,
apart.

 

Also I don’t really see the benefit of renaming files like topcategories.tpl
to categorylist.tpl. What’s wrong with the old name?

 

Regards,

Frank

 

 

 

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Joscha Krug
| marmalade.de
Gesendet: Donnerstag, 11. Oktober 2012 23:09
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Release candidate 1 for OXID eShop version
4.7/5.0

 

Hi guys,

thanks for the new version.
I checked it out.

There are a few questions and hints:

1) Why are Frontend-Controllers directly in application/controllers while
controllers for the backend are in the subfolder /admin? In
application/views you have separated the folders.

2) I have seen that Smarty-Templates are moved to application/views/tplname
while static files to that template still in out/tplname. If you want to
sell ready-made templates that makes everything more complicated.

3) You changed the template-structure from 4.4.8 to 4.5 and now again to 4.7
/ 5.0. Again: If you want to sell ready made templates, like we do with our
mobile Template oxmob.de, that means that there is absolutely no chance to
keep them updated without maintaining separate versions! Please:Think, how
you want to change it - move the files and then leave them, where they are!
Keep the API stable. Keep in mind, that if your changes are that huge, you
will definitivly BREAK things.

4) A feature request according to that would be a more powerful template
inheritance to have three levels (your template - bought template -
azure/basic). Already send that to Erik.

So, keep up the good work but have in mind what the cosequences are for your
partners.

Best Joscha




//-

 

marmalade.de
Joscha Krug

 

 http://www.marmalade.de/ www.marmalade.de
k...@marmalade.de

 

Leibnizstr.25
39104 Magdeburg
GERMANY

 

phone: +49 (0) 391 / 559 22 104
fax:  +49 (0) 391 / 559 22 106

OXMOB | mobile Template
http://www.oxmob.de/?pk_campaign=OXMOB%20%7C%20E-Mail-Linkpk_kwd=normalEma
il 
Das einfach geniale OXID eShop Modul.
Ab sofort in unserem Online-Shop
http://www.marmalade.de/shop/Templates/OXMOB-OXID-eShop-mobile-Template.htm
l?pk_campaign=OXMOB%20%7C%20E-Mail-Linkpk_kwd=normalEmail  erhältlich.

Am 11.10.2012 21:54, schrieb Marco Steinhaeuser:

Hi everybody,
 
RC1 is out for OXID eShop version 4.7/5.0.
Same place for information and links to downloads:
http://wiki.oxidforge.org/Downloads/4.7.0_5.0.0
 
Regards
Marco
___
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] Nested Sets and OXSORT

2012-07-17 Thread Frank Zunderer 
Hi Daniel and Joscha,

 

 using nested sets AND parent_id's makes the code hard to understand.
 You are mixing to different concepts which also doubles potential error
pits.

 

It’s a bit redundant, that’s true, I think of it like an index for fast
access. You have all the information in id/parentid/oxsort, so this can be
seen as “master”, and from there, nested sets structure is built. Oxid
itself uses nested sets so rarely that it might look like the overhead in
maintaining nested sets is not justified. But if you write a module and need
something like “get all childs and subchilds” it is nice to have nested sets
available.

 

Maybe nested sets could be dropped, I don’t know how much the performance
impact would really be if recursion was used in such cases, probably not
really notable. Talking about things that could be dropped, first two things
I would mention are Content Cats and Price Cats, which both seem close to
useless to me, and equally unnecessarily complicate the template and core
code in lots of places.

 

Best Regards, Frank

 

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Joscha Krug
| marmalade.de
Gesendet: Dienstag, 17. Juli 2012 09:22
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Nested Sets and OXSORT

 

Hi Daniel,

 using nested sets AND parent_id's makes the code hard to understand.
 You are mixing to different concepts which also doubles potential error
pits.

You've nailed it! Thats what i wanted to say. I can go with both concepts
alone. But mixing them is really strange! Although you could enter OXSORT
also for subcategories.

Best Joscha


//-

 

marmalade.de
Joscha Krug

 

www.marmalade.de http://www.marmalade.de/ 
k...@marmalade.de

 

Leibnizstr.25
39104 Magdeburg
GERMANY

 

phone: +49 (0) 391 / 559 22 104
fax:  +49 (0) 391 / 559 22 106

OXMOB | mobile Template
http://www.oxmob.de/?pk_campaign=OXMOB%20%7C%20E-Mail-Linkpk_kwd=normalEma
il 
Das einfach geniale OXID eShop Modul.
Ab sofort in unserem Online-Shop
http://www.marmalade.de/shop/Templates/OXMOB-OXID-eShop-mobile-Template.htm
l?pk_campaign=OXMOB%20%7C%20E-Mail-Linkpk_kwd=normalEmail  erhältlich.

___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Nested Sets and OXSORT

2012-07-16 Thread Frank Zunderer 
Hello Joscha,

 

i think nested sets are not used for building the categorytree, it’s built
from id/parentid.

 

Nested sets are also built individually for each main category and contain
no info about sorting of main categories.

 

Regards,

Frank

 

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Joscha Krug
| marmalade.de
Gesendet: Montag, 16. Juli 2012 17:48
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] Nested Sets and OXSORT

 

Hi,

today we discussed the oxcategories-structure.

We are wondering why there is a oxsort field.
As told everywhere, OXID uses nested sets for building the categorytree. So
normaly you don't need a manual sorting-field.

Could you explain why you not just rely on them?

Best Joscha

-- 


//-

 

marmalade.de
Joscha Krug

 

www.marmalade.de http://www.marmalade.de/ 
k...@marmalade.de

 

Leibnizstr.25
39104 Magdeburg
GERMANY

 

phone: +49 (0) 391 / 559 22 104
fax:  +49 (0) 391 / 559 22 106

OXMOB | mobile Template
http://www.oxmob.de/?pk_campaign=OXMOB%20%7C%20E-Mail-Linkpk_kwd=normalEma
il 
Das einfach geniale OXID eShop Modul.
Ab sofort in unserem Online-Shop
http://www.marmalade.de/shop/Templates/OXMOB-OXID-eShop-mobile-Template.htm
l?pk_campaign=OXMOB%20%7C%20E-Mail-Linkpk_kwd=normalEmail  erhältlich.

___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Recent Viewed Products

2012-06-19 Thread Frank Zunderer 
Hi,

 

Last seen products is already built in, but only for detail view. Here is a
module that activates last seen in azure throughout the shop, just add the
views where you want to show it in metadata.php:

 http://forum.oxid-esales.com/showthread.php?t=708page=5
http://forum.oxid-esales.com/showthread.php?t=708page=5

 

Regards,

Frank

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Sai Chandra
Sekhar Madala
Gesendet: Dienstag, 19. Juni 2012 16:52
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] Recent Viewed Products

 

Dear All,

I have a requirement where I have to show the recent viewed products.I have
tried to implement this through a module.

First I have stored the ox-id's of the viewed products inside a session
variable and retrieved them and created an object and loaded the product
using load function.

1) This is the code in details.php for storing session variable.

 

if(isset($_SESSION['views']))
$_SESSION['views']=$_SESSION['views'].,.$oProduct-oxarticles__oxid-value
;
else
$_SESSION['views']=$oProduct-oxarticles__oxid-value;


2) Then I have used the below code in Module

public function getrecentviewproduct(){
$i=0;
if($procoxid = oxSession::getVar('views')){
$sOxid =  explode(, , $procoxid);
foreach($sOxid as $procid){
$oArt = oxNew('oxarticle');
$oArt-load($procid);
$oArtList[$i] = $oArt;
$i++;
}
return $oArtList;
}
return null;
}


This module when registered with start class works fine in start page,but
our requirement is that it should work through out the shop.

Please suggest which class has to be extended so that the above will work
through out the shop.


Thanks  Regards,
Sai Chandra Sekhar.M,
Devblaze Inc.




___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] new module structure in 4.6 and admin include files not working?

2012-05-23 Thread Frank Zunderer 
Hi Xavier,

 

the languagefiles are called module_options.php and reside in
modulefolder/out/admin/language, e.g.
modules/yourmodule/out/admin/de/module_options.php.

 

keys have prefixes SHOP_MODULE_GROUP_, SHOP_MODULE_ and HELP_SHOP_MODULE_.

 

So your file module_options.php could be like

 

?php

$sLangName  = Deutsch;

$aLang = array(

'charset'   = 'ISO-8859-15',

'SHOP_MODULE_GROUP_main' = 'Paybox Einstellungen',

'SHOP_MODULE_paybox_ctx_mode' = 'CTX Mode',

'HELP_SHOP_MODULE_paybox_ctx_mode' = 'Stellen Sie hier
den CTX-Mode ein',

);

 

At least this is what I found out looking at the paypal module.

 

Regards, 

Frank

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Xavier
VILLARD
Gesendet: Mittwoch, 23. Mai 2012 10:34
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] new module structure in 4.6 and admin
include files not working?

 

Hi guys,

I'm currently adapting some modules to be 4.6 compatible.

I made my metadata file which is correct.

For this module I've some options I declared as settings in metadata.php as
follows :

'settings'  = array(

array('group' = 'main', 'name' = 'paybox_ctx_mode', 'type' = 'str',
'value' = 'TEST'), 

array('group' = 'main', 'name' = 'paybox_module_call_method', 'type' =
'str',  'value' = 'curl'),


),

My problem is that I don't know how to manage translations for these
settings.. In the admin area I get the I get translation error messages for
each setting...

Any clue ?

Regards

 

-- 
Xavier



___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general

Re: [oxid-dev-general] Oxid AJAX Bug?

2011-12-09 Thread Frank Zunderer 
Hello Mitch,

i stumbled into the same error:
https://bugs.oxid-esales.com/view.php?id=3405

There is hope that errors will be shown in next version:
https://bugs.oxid-esales.com/view.php?id=3375

Regards,
Frank Zunderer



 -Ursprüngliche Nachricht-
 Von: dev-general-boun...@lists.oxidforge.org [mailto:dev-general-
 boun...@lists.oxidforge.org] Im Auftrag von Mitch Köhler
 Gesendet: Freitag, 9. Dezember 2011 19:08
 An: dev-general@lists.oxidforge.org
 Betreff: Re: [oxid-dev-general] Oxid AJAX Bug?
 
 Hello list,
 
 I found the root of evil.
 It is a line in the details-page's ajax-files:
 [{oxscript add=$( 'ul.js-articleBox' ).oxArticleBox();}]
 
 This method has no (included) source-file and will therefore produce an
 error.
 
 I would really appreciate it, if you don't uncomment console.log()-
 statements that only trigger if an error occurs (as it is currently the
case in
 oxajax.js).
 
 Best Regards,
 Mitch
 ___
 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