Re: [oxid-dev-general] Split CSS files to smaller ones

[Frank Zunderer]

Hi Dainius,

 

first i want to say i agree with most that was said before, especially about
the sheer amount of css. I think the main goal is flexibility and clarity.
So to me the idea of having separate files for different elements sounds
good. For example, a javascript driven Element should have its own js and
also css, like the superfish menu, so if you decide to use your own solution
it can easily be removed. Right now it’s all buried in elements.css and
gui.js. Also the files should be split by groups of pages, like one for
detail and one for checkout. This would make it easier to take some
pages/elements and use them in a different context or different layouts, or
to remove certain elements. I also like the idea of loading these files
during runtime, as it would make even clearer which files are used by a
certain page.

 

About one file vs many files performance: as css-files are only requested
once and then cached, it sounds good to distribute this task among pages to
reduce the loading size of the start page. If files are compiled into one,
this file would have to contain everything again in order to be cached. So I
agree that the performance gain of not loading unnecessary elements would
outweigh the loss due to having several files. Also it would be easier to
deliver minimized layouts that do not make use of many of the possible
elements, like a start page that only contains a menu and a single slider,
and in fact only needs a few lines of css.

 

Regards, Grüße aus München,

Frank Zunderer

 

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Dainius
Bigelis
Gesendet: Donnerstag, 16. Juni 2011 15:44
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] Split CSS files to smaller ones

 

Hi,

 

Currently we are working to improve the code and structure of CSS files.

Just we are not sure about one idea, that we want to implement, so we would
like to ask you about your opinion regarding that.

 

Currently (in eShop 4.5.0 verson) we have ~10 css files, where one of these
(elements) have ~4000 lines of code.

Making any change in that and maintain it became really difficult for
developers. 

 

So we thought that would be good to split this file to the smaller ones
(according the type of elements) and change the structure of other files.

 

As a result of that would be 3-5 files according to the type of page
(details page, list, checkout, main page…). These files would do nothing,
just include the smaller css files for elements, which are really used used
in this particular page.

The advantage of such structure:

-  Much more easy development/changes and maintenance;

-  Scalability of pages, as elements which are not needed in this
page would not be loaded (i.e. elements used only in checkout would not be
loaded in details page).

 

Disadvantage:

-  There are some ideas, that loading more files may reduce the
performance. But we think that such effect may be noticed only during the
first load of the page and then it is cached. But considering what we have
now – it parses all the long (4k lines) file even of some big part of this
is not needed in the page.

 

Also, one of solutions to work with smaller files and deliver one file as
result – is to use the dedicated tools for compiling the css files into one
during deployment.

 

So – please tell your ideas about this concept or any arguments for one or
other solution.

 

Best regards,

Dainius Bigelis

 

 

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

Re: [oxid-dev-general] Merging old and current baskets [T-1KW022X2HH-26]

[Frank Zunderer]

Hi all,

 

Ø  - it is a bit irritating that currently items appear in the basket
without any notice ;-

 

I think that this is mostly irritating because items do NOT appear in the
basket, but only later in order overview. This happens because, if user logs
in during checkout, the process is:

-  Check basket contents

-  Login to proceed (previous basket items are added silently in
background without any notice)

-  At last Step there are now more items in the order overview than
were before in the basket

 

If a user logs in before checkout, I think it’s OK to merge stored contents
with current contents without notice, this seems not irritating to me. So I
would suggest:

-  User logs in during checkout: nothing ever is merged

-  User logs in before checkout: stored basket and current is merged
(eventually with an optional message)

 

Regards,

Frank Zunderer

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von anzido GmbH
Gesendet: Donnerstag, 23. Juni 2011 19:51
An: dev-general@lists.oxidforge.org
Betreff: 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: Mažvydas Skuodas 
An: 
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 don’t 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 “Previously you also added item X and other N items,
Merge? ”. 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.

Mažvydas

From: Dainius Bigelis <mailto:dainius.bige...@oxid-esales.com>  

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 we‘re considering about concept, how to handle basket saved for
user from previous session (when user not finishes the order, so it‘s stored
to DB).

One of the ideas is written in the bugtrack entry:

https://bugs.oxid-esales.com/view.php?id=2260

 

… 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 – 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

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

[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

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

[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

 

 '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] Recent Viewed Products

[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=708&page=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] Recent Viewed Products

[Frank Zunderer]

Hi Sai Chandra,

 

when it is displayed in startpage then it is generally working, and alist is
enabled by default, so maybe the block 'sidebar_boxproducts' is not loaded
in your template for alist. As Tobias pointed out, it is possible to
overload oxviewconfig to have a function available in every

template, yet I think I prefer to control from module where it is displayed,
and not from template.

 

@Tobias:

Problem I see with your code is that the null value is added to the array
aHistoryArticles, and one real article is removed in return.

 

Regards,

Frank Zunderer

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Sai Chandra
Sekhar Madala
Gesendet: Mittwoch, 20. Juni 2012 09:31
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Recent Viewed Products

 

Hi Mr.Marco & Mr.Frank,

@Thanks Mr.Marco.

@Frank .Thank you for the module.As you pointed out it is built in,but only
for detail page.I have used your module and it works fine in detail page as
well as start page but not through out the shop.I have extended the aList &
start classes also I tried to extend oxView & oxUBase, but they do not seem
to work.Please suggest me the class to extend so that it works through out
the shop.

Thanks & Regards,
Sai Chandra Sekhar.M

On Tue, Jun 19, 2012 at 10:49 PM, Frank Zunderer
 wrote:

 

___
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

[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  
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
 
Das einfach geniale OXID eShop Modul.
Ab sofort in unserem Online-Shop
  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

[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  
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
 
Das einfach geniale OXID eShop Modul.
Ab sofort in unserem Online-Shop
  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

[Frank Zunderer]

Hi Tomas,

 

i think it’s more like the other way around, id/parent is used for building
tree etc. and nested sets only in some special cases.

 

Regards,

Frank

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Tomas
Liubinas
Gesendet: Mittwoch, 18. Juli 2012 14:39
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Nested Sets and OXSORT

 

Hi Joscha,

 

Yes, technically category parent id and sorting information is not needed
for nested set functionality, so this information is redundant and is
probably never used when building the tree and selecting categories. However
it could be used for more simple data import. It is easier to define
child-parent relation over parent id field in 3rd party system and then
import it to eShop. Parent id is also useful in cases when nested set values
are screwed for some reason and you need to rebuild the tree completely. 

 

Regards

Tomas Liubinas

 

From: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] On Behalf Of Joscha Krug |
marmalade.de
Sent: Monday, July 16, 2012 9:45 PM
To: dev-general@lists.oxidforge.org
Subject: Re: [oxid-dev-general] Nested Sets and OXSORT

 

Ok, seems like OXID is NOT using nested sets?!

The question is more like: Why do we have left+right although we use
ParentID and Sorting?
Isn't that a bit too redundant?

Regards,
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-Link&pk_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-Link&pk_kwd=normalEmail>  erhältlich.

Am 16.07.2012 19:31, schrieb Björn Lange:

Hi All,

2012/7/16 Frank Zunderer  

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

 

And the sorting becomes easier, because every category with oxparent =
'oxrootid' has oxleft=1 at the moment.

 

Regards,

Björn

 

-- 

_
WBL Konzept, Beerden & Lange GbR
Björn Lange
Geschäftsführender Gesellschafter
 
Luxemburger Straße 266
50937 Köln

Bilker Straße 34
40213 Düsseldorf

Telefon: 0211 942 120 30 | Fax: 0211 192 120 32
 <http://www.wbl-konzept.de/> www.wbl-konzept.de |
<http://www.facebook.com/wbl.konzept> www.facebook.com/wbl.konzept |
<mailto:b.la...@wbl-konzept.de> b.la...@wbl-konzept.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] Release candidate 1 for OXID eShop version 4.7/5.0

[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

 

  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
 
Das einfach geniale OXID eShop Modul.
Ab sofort in unserem Online-Shop
  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] Question about Shipping Costs

[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 :

> Hi, already solved it myself. Was a cache problem.
> 
> Greetings.
> 
> Am 18.11.2012 um 17:39 schrieb Christoph Daum :
> 
>> 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] OXID Deployment System + The Community

[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:  
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:  
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

 

  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."

  _  

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:  
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

Re: [oxid-dev-general] How to access $oViewConf->getActiveClassName() in Widget-Template

[Frank Zunderer]

Hi all,

 

i did not find a way to do this also. $aViewsChain seems to be unused, i 
noticed some template calls use _parent to pass the current value of 
getClassName to the widget, but there should be some way to get the main 
controller class without having to do this imho.

 

Regards,

Frank Zunderer

 

 

 

Von: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Lange, Björn
Gesendet: Montag, 3. Dezember 2012 17:12
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] How to access $oViewConf->getActiveClassName() in 
Widget-Template

 

Hi all,

 

I did not find a way to get the active view name in a template, displayed by 
the new widget structure. OXID uses the "$aViewsChain" in the 
oxShopControl-Chain for loading the template, but i did not see a usage of this 
chain displaying a widget.

 

protected function _initializeViewObject($sClass, $sFunction, $aParams = null, 
$aViewsChain = null)

{

$myConfig = $this->getConfig();

 

// creating current view object

$oViewObject = oxNew( $sClass );

 

// store this call

$oViewObject->setClassName( $sClass );

$oViewObject->setFncName( $sFunction );

$oViewObject->setViewParameters( $aParams );

 

$myConfig->setActiveView( $oViewObject );

 

 

// init class

$oViewObject->init();

 

return $oViewObject;

}

 

Can you give me a hint? $oViewConf->getActiveClassName() returns the 
widget-Class.

 

Regards,

Björn

 

-- 

_
WBL Konzept, Beerden & Lange GbR
Björn Lange
Geschäftsführender Gesellschafter
 
Luxemburger Straße 266
50937 Köln

Bilker Straße 34
40213 Düsseldorf

Telefon: 0211 942 120 31 | Fax:  0211 942 120 32
 <http://www.wbl-konzept.de/> www.wbl-konzept.de |  
<http://www.facebook.com/wbl.konzept> www.facebook.com/wbl.konzept |  
<mailto:b.la...@wbl-konzept.de> b.la...@wbl-konzept.de 

 

___
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

[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] Adding params to oxlocator

[Frank Zunderer]

Hi Daniel,

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

_addSpecialParam( $sParams );
}
protected function _addPageNrParam( $sUrl, $iPage, $iLang = null )
{
$sUrl = parent::_addPageNrParam( $sUrl, $iPage, $iLang );
return $this->_addSpecialParam( $sUrl );
}
protected function _addSpecialParam( $sUrl ){
$sUrl .= "&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

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

[Frank Zunderer]

Hi Daniel,

why do you think more modules are needed? The code adds a param to paging,
view, sorting and articles per page.

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 17:10
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Adding params to oxlocator

Hi Frank,

that was my first idea. But when you start to implement it like that, you
very soon find out that you need a lot more modules.
Then I stopped because my thought was: "Just for adding a simple param one
needs to create a handful of modules? This is way too complicated! 
There must be a better way. "
That's why I ask here. My hope is that someone says: "Hey, it's easy - just
call method X in class Y and off you go".
Or if Mr Someone decides to not say anything because it really is not
possible in a fast/easy way, I hope that OXID will implement something like
that in future releases.

Best regards,

Daniel Schlichtholz

Am 05.07.2013 16:02, schrieb Frank Zunderer:

> Hi Daniel,
>
> best practice i don't know, but maybe something like the following 
> module for search could be useful:
>
>  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 .= "&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

___
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] Adding params to oxlocator

[Frank Zunderer]

Hi Daniel,

you could exchange addPageNrParam with generatePageNavigationUrl:

_addSpecialParam( $sParams );
}
public function generatePageNavigationUrl()
{
$sUrl = parent::generatePageNavigationUrl();
return $this->_addSpecialParam( $sUrl );
}
protected function _addSpecialParam( $sUrl ){
$sUrl .= "&test=test";
return ( $sUrl );
}
}

Then almost only locator links should have the param, almost because also
comparelinks have the param, but I think it's not possible to exclude them
without template changes as the only changeable variable in sort.tpl is
$_additionalParams, which is retrieved by $oView->getAdditionalParams(), and
the same method is used in compare_links.tpl.

Regards,
Frank Zunderer




-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 20:24
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Adding params to oxlocator

Hi Frank,

when I understand it right, it also adds the params to links to e.g. CMS
pages or in the footer where they mustn't appear.

Best regards,

Daniel Schlichtholz

Am 05.07.2013 18:39, schrieb Frank Zunderer:

> Hi Daniel,
>
> why do you think more modules are needed? The code adds a param to 
> paging, view, sorting and articles per page.
>
> 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 17:10
> An: dev-general@lists.oxidforge.org
> Betreff: Re: [oxid-dev-general] Adding params to oxlocator
>
> Hi Frank,
>
> that was my first idea. But when you start to implement it like that, 
> you very soon find out that you need a lot more modules.
> Then I stopped because my thought was: "Just for adding a simple param 
> one needs to create a handful of modules? This is way too complicated!
> There must be a better way. "
> That's why I ask here. My hope is that someone says: "Hey, it's easy - 
> just call method X in class Y and off you go".
> Or if Mr Someone decides to not say anything because it really is not 
> possible in a fast/easy way, I hope that OXID will implement something 
> like that in future releases.
>
> Best regards,
>
> Daniel Schlichtholz
>
> Am 05.07.2013 16:02, schrieb Frank Zunderer:
>
>> Hi Daniel,
>>
>> best practice i don't know, but maybe something like the following 
>> module for search could be useful:
>>
>> > 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 .= "&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
>&

Re: [oxid-dev-general] How to remove modules completely

[Frank Zunderer]

Hi All,

 

i think supplying built-in debugging tools is not the way to go, the module
loading process just needs to be more stable. There should be no possible
way to corrupt module info in DB. There are several ways where things can go
wrong, for example:

 

Question: There are entries whose files do not exist, do you want to delete
them? Yes: I want a working shop, No: I want rubbish in my DB? Why would
anyone ever want to choose no? If no is chosen, you'll get "Module cannot be
loaded" if you have moved the module. Logging off and on fortunately brings
up the dialog again.

 

When a module is moved, sometimes the wrong path is still in DB
(aModulePaths). The module appears in the list, but empty, no title or
anything, this shouldn't be possible. Deleting aModulePaths helps in this
case.

 

Blocks never get updated or removed once written. I wrote myself a module
that removes blocks when deactivating a module, all info is in the module
anyway.

 

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 OLIGOFORM
GbR
Gesendet: Mittwoch, 17. Juli 2013 14:25
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] How to remove modules completely

 

+1 for that, Joachim!

oliver

Am 17.07.2013 um 14:19 schrieb Joachim Barthel :





Guys from OXID, take it as an experience and offer us in future some
built-in functions, because trying one module after the next and deleting
thing somehow in the database doesn't look very serious, esp. when you have
to do this at the customers shop ;-)

 

___
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

[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 
 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" 
 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  
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  




-- 

Mit freundlichen Grüßen, 
Ahmad 

+4917645387460  


_

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

[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] Extending mobile Theme with modules

[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

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

[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

Re: [oxid-dev-general] Pros and cons for module-connectors

[Frank Zunderer]

Hello,

 

one problem with those connectors is that they add value for the developer,
but not so much for the customer. This may be the reason why no one likes
those connectors, except the developers their own ;-). The more
sophisticated they are, the more they add errors and do not give the
impression of a unified experience when installing modules.

 

Dependencies in general may be a problem but not so much I think. As it is,
it seems connectors introduce more dependencies because every module depends
on the existence of the correct version of the corresponding connector.

 

What I would really appreciate is a module installer/updater/uninstaller
(that does not contain any module functionality, so it wouldn’t be required
for the modules to work) on github, until this functionality is built into
the core.

 

Regards,

Frank Zunderer

 

 

 

 

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Stefan
Moises
Gesendet: Dienstag, 21. Januar 2014 11:42
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Pros and cons for module-connectors

 

Hi,

yes, some type of dependency management is a must for the OXID module
system!

As a workaround, we have started a simple module managing dependencies
("smx_module_deps"), at the moment you can only add other module ids which
your module depends on, e.g. in metadata.php you can add:

'depends' => array(
'smx_filialabholung'
),
'settings' => array(),

On our todo list are some more features like adding versions, e.g. like so

'depends' => array(
array('id' => 'smx_filialabholung', 'version' => '1.1'),
),
'settings' => array(),

What it does at the moment is simply to make sure that a module can't be
manually disabled if other modules depend on it. We have to extend that so
that the shop also doesn't automatically disable modules if metadata.php has
new "extend" entries etc.

But ideally, this should really be part of the OXID core

cheers,
Stefan

Am 21.01.2014 09:38, schrieb Joscha Krug | marmalade GmbH:

Hi,

same for me: I also don't like them. If you have dependencies between
modules go for composer or something the like.

Best would be if OXID could come up with an extension in the metadata.php in
which you could tell "this module is based on that other module".

Best regards

Joscha


//-

 
Joscha Krug
marmalade GmbH

 

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-Link&pk_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-Link&pk_kwd=normalEmail>  erhältlich.

Am 21.01.2014 08:44, schrieb Marcel Müller:

Hey! 

 

I don’t like such additional connector modules. They have their own bugs and
generating system-wide errors, mostly. Especially when the module has an own
style and/or database tables far from oxid. I had scenarios within a
customer tried to remove a connectors modul and gets a lot of trouble with
the system. But if you want to get rich with support, this could be a model
;)

 

What about a wrapper script inside every module or inside the vendor
structure? With that you can also check the versions and be agile.

 

Mit freundlichen Grüßen

Marcel Müller
Webentwicklung / Projektmanagement
eMail: m...@aikme.de

 <http://www.aikme.de/> Das Bild wurde vom Absender entfernt.


aikme GmbH
Rheinstraße 43-45
55116 Mainz / Deutschland
Telefon: 06131 92 06 503
Telefax: 06131 92 08 334
www.aikme.de <http://www.aikme.de/> 

 

aikme GmbH 
Geschäftsführer: Sascha Coldewey 
Sitz in Mainz, Registergericht: Mainz 
Registernummer: HRB 44835 
Umsatzsteuer ID: DE282561622 

Am Dienstag, 21. Januar 2014 um 08:31 schrieb Roman Allenstein:

Hi folks,

 

me and my team are developing a concept for us, how to develop modules 

for oxid. We are now at the point where we have to decide to develope a 

connector-module for all our coming modules or not.

 

We know that some agecies use their own connector to integrate their 

modules in oxid. And i am pretty unsure if this is the way to go because 

oxid provides a standardized way to integrate modules.

 

Whats your pros and cons for using an own connector?

 

Greets

Roman

-- 

Dipl.Winf. (FH) Roman Allenstein

Sales Manager E-Commerce

Spark 5 GmbH

Lutherstraße 7

27570 Bremerhaven

 

Fon: +49-471-4836-3547

Fax: +49-6151-8508-111

 

Mail: roman.allenst...@spark5.de

Web: http://www.spark5.de

--

 

Geschäftsführer:

Dipl. Designer Till 

Re: [oxid-dev-general] Blocks save path changed in 4.8?

[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] Query with OXID 4.8.x

[Frank Zunderer]

Hi,

 

for number two you can set $this->blSkipViewUsage = true; in config.inc.php,
recreate views and take it out again.

 

Regards,

Frank

 

Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Hardik
Badani
Gesendet: Mittwoch, 12. März 2014 06:59
An: Dev General
Betreff: [oxid-dev-general] Query with OXID 4.8.x

 

Hello All,

 

Greetings!!

 

I have found two issues/points related to OXID latest version 4.8.x

 

1) I have tried to use locally CE version and there when I tried to logged
in admin then it takes lots of time to logged in, which was not in earlier
version. I found that it tries to call some curl request which might be
restricted at my side so Can I stop that request calling or is it some other
problem..?

 

2) If I develop a new shop with version 4.8.x in locally all things are
working fine but when I tried to upload whole shop on server there in DB
import views creation are restricted, due to which it shows shop offline on
server, with earlier version it was allow to use admin and from there we can
easily updates views which were restricted but with this new version its not
possible.

So, it requires to install everytime new shop and there we need to merge
changes which we had done locally.

Is there any solution to this..?

 

Thanks in Advance.

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

Re: [oxid-dev-general] No unique indices in oxobject2* tables

[Frank Zunderer]

Hi,

 

+1, i suggested this here: https://bugs.oxid-esales.com/view.php?id=5666

If an importer assigns an article twice to a category, number of articles 
displayed in list view is wrong.

 

@Michael Gerhardt, this index is not unique.

 

Regards,

Frank

 

Von: dev-general-boun...@lists.oxidforge.org 
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Hans-Peter 
Szcazmus
Gesendet: Donnerstag, 20. März 2014 10:22
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] No unique indices in oxobject2* tables

 

Dear developers,

 

why are there no unique indices in the oxobject2* tables?

 

Example for oxobject2category:

It shouldn't be possible to assign a cateogory to an article twice.

With a pure MySQL INSERT statement that would be possible.

Wouldn't it make sense to create a unique index with OXOBJECTID and OXCATNID?

 

Best regards,
Hans Peter

___
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

[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 :





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] Recalculation of Delivery Costs / Splitting Orders

[Frank Zunderer]

Hi,

maybe it's because of this bug:
https://bugs.oxid-esales.com/view.php?id=4385 
oxDeliveryList::getDeliveryList is called in oxbasket:: _calcDeliveryCost
$this->_aDeliveries is not resetted, so if you call the method multiple
times, _aDeliveries add up.

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 Alex Schwarz
Gesendet: Donnerstag, 25. September 2014 18:08
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] Recalculation of Delivery Costs / Splitting
Orders

Hi,

I am working on a module to split one OXORDER into many, based on the
vendors. For now I clone the actual order object, set my order articles I
want for this Order, call recalculate functions and save. 

Everything is working fine but the delivery costs. In the last order I
always have the delivery costs of the previous one. So it seems on the last
order I have the delivery costs of the original order (all delivery costs).
I think there is a cache or something. Or it reload from the session basket?
Working the whole day on it, can’t figure it out.

I already call the reload methos (reloadDelivery true, reloadDiscount true
and recalculateOrder)

Anyone got an idea? 

Alex Schwarz / active value
___
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] Can't remove old module entries

[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

AW: Database utf8 and latin1 questions

[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 
mailto:gregor.hyn...@oxid-esales.com>> 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

AW: Database columns missing in OXID eShop v6

[Frank Zunderer]

Hello Michael,

only the keys are dropped, not the fields.

Regards,
Frank Zunderer

-Ursprüngliche Nachricht-
Von: Michael Ochmann [mailto:o...@ain.wtf] 
Gesendet: Dienstag, 3. April 2018 11:40
An: OXID dev-list 
Betreff: Database columns missing in OXID eShop v6

Hello together,

in the sql-migrations for OXID v6 i noticed, that the fields "OXARTNUM"
and "OXSTOCK" are getting dropped without the hint for a possible
replacement anywhere else. Can somebody tell me, where this information
is supposed to live after the migrations and in v6?


-- 
best regards

Michael Ochmann
CTO, Softwarearchitect, OXID development
AiN Entertainment

[oxid-dev-general] New Folder Structure in 4.7.0

[Frank Zunderer IT Beratung]

Hi All,

i noticed the new folder structure in 4.7.0, I have a question regarding
the new structure:

According to the wiki, the structure is as follows:
/eshop/core - OXID eShop framework directory
/eshop/application - application directory:
/models - contains business logic models
/controllers - contains page controllers
/views - contain templates
/components - folder for components that can be reused in multiple
pages.
/eshop/modules - folder for modules.

This looks much more intuitive than having controllers in "views"
directory. What I don't really like is the directory "/eshop/core - OXID
eShop framework directory". Sounds good, but in my opinion this is not
really an independent framework. There are lots of references to
specific models in there, for example oxutilscount is far from being an
independent counting class, it contains methods like
"setPriceCatArticleCount" etc. So I think those files would better
reside in the application directory, what is your opinion?

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

[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