Re: [oxid-dev-general] Oxid MultiLangTables
Hi Michael,
unfortunately there is one additional trap. The solution proposed by Alexander
does of course work, but it will still require you to manually recreate all
views.
But shoudn't it be possible to do this automatically in the onActivate handler,
you ask? Of course it should, there is even an updateViews method, that does
the hard work for you. However the oxLang module, which tells the system about
your new multilang tables, is not active yet in this handler, so you're out of
luck.
regards
Gernot
Von: dev-general-boun...@lists.oxidforge.org
dev-general-boun...@lists.oxidforge.org im Auftrag von Michael Wagner
michael.wag...@spark5.de
Gesendet: Donnerstag, 6. Februar 2014 14:58
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Oxid MultiLangTables
Sometimes it's simple. Thank you for the little hint. :-)
Greets Michael
Am 06.02.2014 13:56, schrieb Roman Allenstein:
This is a very useful hint. thanks for that!
Greets
Roman
Am 06.02.2014 13:18, schrieb Alexander Kludt:
Hi there,
I always extend that array through my own module:
?php
class agformsmanager_oxlang extends agformsmanager_oxlang_parent{
public function getMultiLangTables(){
$aTables = parent::getMultiLangTables();
$aTables = array_merge($aTables,
array('agforms','agformfields','agformmailings'));
return $aTables;
}
}
From what I can see this works even if I add new languages.
--
mit freundlichen Grüßen
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.
Michael Wagner mailto:michael.wag...@spark5.de
Donnerstag, 6. Februar 2014 13:03
Hello,
I have a table containing the text. This I did in the config.inc.php:
aMultiLangTables entered. Iif I will now adding a new language but the
OXID tables extended not my own. must be set even something extra or
you have to do this yourself here. If you have the Views Updated?
- Registered table
- Created a new language
- Cleared cache
- Views updated.
My own table remains unchanged.
Does anyone have an idea what it is?
M. Wagner
___
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
--
Michael Wagner
Senior Software Developer
--
Spark 5 GmbH
Rheinstr. 97
64295 Darmstadt
Germany
--
Fon: +49-6151-8508-027
Fax: +49-6151-8508-111
Mail: michael.wag...@spark5.de
Web: http://www.spark5.de
--
Geschäftsführer:
Dipl. Designer Till Middelhauve
Dipl. Informatiker Witold Wegner
Amtsgericht Darmstadt, HRB 7809
--
Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail sind nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.
___
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] Delete Cache of specific product
Hi, it is possible, but I don't know if there is a module around, that can do that for you. The problem is that OXID does not cache product information but the states of controllers (still called views in 4.6). That basically translates to pages you can see in your shop (details, product list, start page). With the default cache backend these page states are stored by calculating a view-ID and using its MD5 sum as a filename in the tmp/ directory. You can manually delete these files to clear a specific part of the cache. Unfortunately every controller is allowed to use its very own method to create such view-IDs, so you have to manually look up every getViewId() method and study them. (e.g. here: http://docu.oxid-esales.com/CE/sourcecodedocumentation/4.6.6.54646/) So if you want to remove all cached pages for a specific product you have to at least remove its detais page and every category page and the manufacturers page it appears in. There might even be more, depending on your cache settings. Therefor in most cases it's easier to just clear the whole cache and have it rebuild by a crawler. regards Gernot Payer Von: dev-general-boun...@lists.oxidforge.org dev-general-boun...@lists.oxidforge.org im Auftrag von Friedemann Stoffregen friedem...@stadesign.de Gesendet: Montag, 23. September 2013 08:29 An: dev-general@lists.oxidforge.org Betreff: [oxid-dev-general] Delete Cache of specific product Good morning, everyone! Does anyone know if it's possible to delete the cache of a specific product (manufacturer, category, …)? Instead of deleting the whole tmp/ directory, I just want to delete the files needed to generate the product list, the detail-page. I'm currently using the latest Version of Oxid EE 4.6. regards, Friedemann Stoffregen ___ 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 Vendor folder
Hi Matthias,
your metadata.php ist missing some entries. Unfortunately you have to include
all of them ('files'. 'extend', 'templates', 'blocks', 'events', 'settings')
even if they are empty.
If entries are missing then you won't be able to activate the module. Yes, the
non-existent error message does not help.
Good luck!
Gernot
Von: dev-general-boun...@lists.oxidforge.org
dev-general-boun...@lists.oxidforge.org im Auftrag von Matthias Kluth
kl...@unit-m.de
Gesendet: Donnerstag, 1. August 2013 12:58
An: dev-general@lists.oxidforge.org
Betreff: Re: [oxid-dev-general] Oxid Vendor folder
Hi Johannes,
it looks like this:
?php
/**
* comment description
*
* PHP version 5
*
* @category An/Category
* @package Some/Package
* @author Matthias Kluth kl...@unit-m.de
* @license http://www.example.org/license.html tba.
* @link http://www.abc.de
*/
/**
* Metadata version
*/
$sMetadataVersion = '1.1';
$aModule = array(
'id'='modulename',
'title'='Some fancy title',
'extend'=array(
'erp'=
'vendorname/modulename/application/controller/someclass',
),
);
On 01.08.2013 11:46, Johannes Ackermann wrote:
Hi,
what does your metadata.php look like?
--Johannes
-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von Matthias Kluth
Gesendet: Donnerstag, 1. August 2013 11:40
An: dev-general@lists.oxidforge.org
Betreff: [oxid-dev-general] Oxid Vendor folder
Good morning,
I'm just trying to add a new module-folder inside of a vendor folder.
So my setup is:
modules/
|
|--vendorname
|--vendormetadata.php
|--modulename
|
|--metadata.php
But as I want to activate it inside my oxid installation, it only shows me
the vendorname as modulename and tells me: Module has no metadata file, so
for registering...
So it doesn't seem to recognize my vendor folder, right?
Did I miss something? I guess it's just a small error, but I can't find it.
I really appreciate your help.
Have a nice day,
Matthias Kluth
___
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] How to remove modules completely
And if I may add, after you fixed the syncing between the module state in the db and the module state in the module directory, please make onActivate handlers more comfortable. A common use case for onActivate is adding new database tables and columns. However there are obstacles: 1. There is no method to empty tmp/, you have to implement that yourself 2. There is no reasonable way to introduce new multilangual database tables. If you make such a table known to the system by extending oxLang, you still won't have it available in onActivate, therefore no views are created. It might be possible to do this by manipulating the relevant config parameter on the fly, but that is still an ugly hack. And please add error messages! You never know what went wrong. If the module doesn't activate I expect a decent error message! And if the onActivate handler is not found, I expect a decent error message as well! At the moment developing with the new module system is no fun at all, please feel free to improve on that. regards Gernot Payer Von: dev-general-boun...@lists.oxidforge.org dev-general-boun...@lists.oxidforge.org im Auftrag von Joachim Barthel jobart...@gmail.com Gesendet: Mittwoch, 17. Juli 2013 22:09 An: dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] How to remove modules completely Maybe my last statement was too short or misunderstandable: I do not want to have a built-in function for fixing problems caused by a not sufficient implementation. The module loader itself has to be extended. - Joscha has reported, that upgrading a module with new blocks kills the mechanism - I found out, that moving the module one level deeper (by inserting the vendor folder) kills it - ... Therefore, please take some time and make the really good and powerful idea of module registration to a stable solution, which - doesn't come to a deadlock on standard situations - displays error messages, when the data (eg. metadata.php) are wrong Cheers Joachim Joachim Barthel - OxAdshttp://exchange.oxid-esales.com/de/Marketing/Produktmarketing/OxAds-0-3-Stable-CE-4-3-x-4-7-x.html -- OxProbshttp://exchange.oxid-esales.com/de/Datenmanagement/Produktdaten/OxProbs-0-4-Stable-CE-4-3-x-4-7-x.html -- Piwik-Pluginhttp://exchange.oxid-esales.com/de/Controlling/Data-Mining/OXID-Plugin-fuer-Piwik-0-10-Stable-CE-4-3-x-4-7-x.html -- jxAttrEdithttp://exchange.oxid-esales.com/de/Datenmanagement/Artikel-bearbeiten/jxAttrEdit-0-2-Stable-CE-4-7-x.html -- jxExcptnshttp://exchange.oxid-esales.com/de/OXID/Weitere-OXID-Extensions/jxExcptns-0-1-1-Stable-CE-4-7-x.html -- jxSaleshttp://exchange.oxid-esales.com/de/Shopping-Prozess/Kundenmanagement/jxSales-0-2-Stable-CE-4-7-x.html 2013/7/17 Arturas Sevcenko arturas.sevce...@oxid-esales.commailto:arturas.sevce...@oxid-esales.com Interesting, alone - we couldn't reproduce it. But actually we were interested in investigating this issue (Frank thanks for your useful hints!) and will request a task for that. Actually, the debugging functionality was intentionally published as a module as we wanted to avoid users with no technical knowledge to play around with it. Well - the module should have been made more official. Arturas Sevcenko Software Developer From: dev-general-boun...@lists.oxidforge.orgmailto:dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun...@lists.oxidforge.orgmailto:dev-general-boun...@lists.oxidforge.org] On Behalf Of Frank Zunderer Sent: Wednesday, July 17, 2013 4:39 PM To: dev-general@lists.oxidforge.orgmailto:dev-general@lists.oxidforge.org Subject: Re: [oxid-dev-general] How to remove modules completely 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-777250tel:08105-777250 0173-8362768tel:0173-8362768 it-berat...@zunderer.demailto:it-berat...@zunderer.de Von: dev-general-boun...@lists.oxidforge.orgmailto:dev-general-boun...@lists.oxidforge.org [mailto:dev-general-boun
[oxid-dev-general] When will the db access code be replaced with a real framework?
Hi list, it's probably safe to say that we all have had problems with using the db access framework of the OXID shop. A few typical examples are: - fields are not read from the db - fields are not written to the db - typos are hard to find and even the best IDE can't help you Now I had the misfortune to encounter this little gem: https://bugs.oxid-esales.com/view.php?id=4930 So, dear OXID developers, when will you finally drop your clumsy db access framework and replace it with a real framework? To clarify, I'm only talking about methods from oxBase like magic getter for coretable__fieldname, assign, selectString and similar stuff. E.g. it would be really nice if $user-fname would give me the user's first name and $user-country would give me a fully loaded oxCountry object. regards Gernot -- *** Dipl.-Inf. Gernot Payer Software-Entwickler shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Amtsgericht Nürnberg HRB 21703 GF Friedrich Schreieck Tel.: 0911/25566-17 Fax: 0911/25566-29 pa...@shoptimax.de http://www.shoptimax.de *** ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Translations for module settings? How?
Hi Nicolas, thanks a lot, that helped! :) regards Gernot Am Thu, 24 Jan 2013 15:27:10 +0100 schrieb Nicolas Hodin nho...@noxnet.fr: Hi Gernot, You will find some information on translating module settings on this url : http://www.oxid-esales.fr/gestion-des-modules-fichier-module_options-php/ . Sorry it's french, but you will easily find the main information that you have to create this language file : modules\module_name\out\admin\language_code\module_options.php . Best regards, Nicolas Hodin www.takeitweb.fr 2013/1/24 Gernot Payer pa...@shoptimax.de Hi devs, I tried to include module settings into a module via the settings parameter in the metadata.php. This part worked, however having translated texts for these options seems to be impossible. So far I tried lang/de/my_module_lang.php, out/lang/de/my_module_lang.php and out/admin/de/my_module_lang.php, all inside the module/my_module directory. None of them worked. Using /views/admin/de/cust_lang.php worked, but that would be bad style, as you are supposed to put all your module files inside your module directory. Can anyone give me a hint how to do this? regards Gernot -- *** Dipl.-Inf. Gernot Payer Software-Entwickler shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Amtsgericht Nürnberg HRB 21703 GF Friedrich Schreieck Tel.: 0911/25566-17 Fax: 0911/25566-29 pa...@shoptimax.de http://www.shoptimax.de *** ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general -- *** Dipl.-Inf. Gernot Payer Software-Entwickler shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Amtsgericht Nürnberg HRB 21703 GF Friedrich Schreieck Tel.: 0911/25566-17 Fax: 0911/25566-29 pa...@shoptimax.de http://www.shoptimax.de *** ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] new module handling
Hi Manuel,
yes, that's a good way to do this manually and with pre-4.6.x versions
it was the only way.
But now that we have a real module configuration interface, it's about
time that we developers get some advantage out of it. ;)
regards
Gernot
Am Tue, 22 Jan 2013 12:50:34 +0100
schrieb Manuel Reiß manuel.re...@mediaopt.de:
Hi Gernot,
to keep module-dependencies inside tpls failsafe, we're currently
using following way:
extend (e.g. oxcmp_utils) or create a component or oxViewConfig and
set a tpl-variable:
public function render()
{
//activate module for templates
//you could also add some addional checks here as well...
$this-getParent()-_aViewData['my_module__isActive'] = true;
return parent::render();
}
therefore your tpl-integration looks like this:
[{if $my_module__isActive}]
[{ $oView-my_module__method() }]
[{/if}]
your suggestion however, sounds much nicer indeed :)
Best,
Manuel
manuel.re...@mediaopt.de | www.mediaopt.de
derksen mediaopt gmbh | elbestrasse 28/29 | 12045 berlin | +49 (30)
34 09 42-77 | fax-66 | Amtsgericht Charlottenburg | HRB 120935 B |
ust.-id DE265886017 | geschäftsführer dipl.-ing. philipp derksen
-Ursprüngliche Nachricht-
Von: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] Im Auftrag von
Gernot Payer Gesendet: Montag, 21. Januar 2013 11:28 An:
dev-general@lists.oxidforge.org Betreff: Re: [oxid-dev-general] new
module handling
Dear Core-Team,
let me add one more thing as Joscha and Christian have already
covered most major points.
Dependencies between modules and templates are not handled at all.
Yes, there is the tpl blocks feature which might work nicely for
defined changes to a standard template set. But the more common case
for agencies is to do a comlete redesign of a template set and to
change a lot of things. Many of those changes of course depend on
modules.
So now a few (or all) modules deactivate themselves for one reason or
another and while the shop might still run, as soon as you hit a page
with module dependencies in its templates, you are screwed.
How about something like this:
[{oxdep module=mymodule}]
[{ $oView-mymodule_method() }]
[{/oxdep}]
If module mymodule was deactivated, oxdep would output something
like spanModule 'mymodule' not active/span.
Another bonus of this would be inline documentation, you can directly
see that this is no standard feature and in which module it is
located.
regards
Gernot
Am Mon, 21 Jan 2013 00:43:09 +0100
schrieb Christian Lehmann lehm...@unit-m.de:
Dear Core-Team.
I really like the way that I am able to extend OXID with modules,
inherit templates, etc. This is what sets OXID apart from other
shop solutions.
But this module handling can become quite frustrating, time
consuming and annoying.
Even the slightest mistake can break the complete shop and it can
take forever to get it working again.
This makes working in teams so much harder than it should be since
most of the devs really do use helpers.
Think: 10 Devs, GIT and one QA-Department that moved one or more
modules to a different folder because of the better name --
endless work after pull!
Think: a complicated module with an error in something essential
like noticelist -- module disabled and complete shop gone.
I just dont want to end up having to add a module for each and
every function I add.
It might sound exaggerated but I hope you get the point.
So: +1 to Joscha's Mail ... should rather be a +100 :)
Best Regards,
Christian
Am 20.01.2013 23:18, schrieb Joscha Krug | marmalade.de:
Dear OXID Core-Team,
now we've used the new module system in many projects.
It makes activating and deactivating in most cases very easy.
But it gets very hard sometimes, like when modules deactivate
themselves or you get those strange red bars in the backend.
What are my thoughts about all that:
I think the metadata.php helps a lot and is the right place for
the base configuration. Great job!
What i don't like is that the ModuleID must be exactly the module
path. This is simply redundant.
Either you want to have the module path,then we should not set it
again OR it is an own key like a module-identifier that is unique
in the OXID world (maybe there could be a central repository
where you could register new ones) - which i think is the right
way.
After that, you store someof the metadata informations in the
database. Why? If you remove some of the classes, files,... your
module leads to those strange red entries as mentioned before. I
think you had good reasons to do so - could you explain them?
Maybe we together find another solution that is cleaner and
doesn't need that double-storeing thing.
Then, there is amissing featurein my opinion: Dependencies to
other modules
Re: [oxid-dev-general] new module handling
Hi Saulius,
thank you and I'm looking forward to it!
regards
Gernot
Am Tue, 22 Jan 2013 09:57:17 +
schrieb Saulius Stasiukaitis saulius.stasiukai...@oxid-esales.com:
Hello Gernot,
Thank you for this suggestion it looks very well. We will definitely
take it into consideration.
Saulius Stasiukaitis
OXID developer
-Original Message-
From: dev-general-boun...@lists.oxidforge.org
[mailto:dev-general-boun...@lists.oxidforge.org] On Behalf Of Gernot
Payer Sent: Monday, January 21, 2013 12:28 PM To:
dev-general@lists.oxidforge.org Subject: Re: [oxid-dev-general] new
module handling
Dear Core-Team,
let me add one more thing as Joscha and Christian have already
covered most major points.
Dependencies between modules and templates are not handled at all.
Yes, there is the tpl blocks feature which might work nicely for
defined changes to a standard template set. But the more common case
for agencies is to do a comlete redesign of a template set and to
change a lot of things. Many of those changes of course depend on
modules.
So now a few (or all) modules deactivate themselves for one reason or
another and while the shop might still run, as soon as you hit a page
with module dependencies in its templates, you are screwed.
How about something like this:
[{oxdep module=mymodule}]
[{ $oView-mymodule_method() }]
[{/oxdep}]
If module mymodule was deactivated, oxdep would output something
like spanModule 'mymodule' not active/span.
Another bonus of this would be inline documentation, you can directly
see that this is no standard feature and in which module it is
located.
regards
Gernot
Am Mon, 21 Jan 2013 00:43:09 +0100
schrieb Christian Lehmann lehm...@unit-m.de:
Dear Core-Team.
I really like the way that I am able to extend OXID with modules,
inherit templates, etc. This is what sets OXID apart from other
shop solutions.
But this module handling can become quite frustrating, time
consuming and annoying.
Even the slightest mistake can break the complete shop and it can
take forever to get it working again.
This makes working in teams so much harder than it should be since
most of the devs really do use helpers.
Think: 10 Devs, GIT and one QA-Department that moved one or more
modules to a different folder because of the better name --
endless work after pull!
Think: a complicated module with an error in something essential
like noticelist -- module disabled and complete shop gone.
I just dont want to end up having to add a module for each and
every function I add.
It might sound exaggerated but I hope you get the point.
So: +1 to Joscha's Mail ... should rather be a +100 :)
Best Regards,
Christian
Am 20.01.2013 23:18, schrieb Joscha Krug | marmalade.de:
Dear OXID Core-Team,
now we've used the new module system in many projects.
It makes activating and deactivating in most cases very easy.
But it gets very hard sometimes, like when modules deactivate
themselves or you get those strange red bars in the backend.
What are my thoughts about all that:
I think the metadata.php helps a lot and is the right place for
the base configuration. Great job!
What i don't like is that the ModuleID must be exactly the module
path. This is simply redundant.
Either you want to have the module path,then we should not set it
again OR it is an own key like a module-identifier that is unique
in the OXID world (maybe there could be a central repository
where you could register new ones) - which i think is the right
way.
After that, you store someof the metadata informations in the
database. Why? If you remove some of the classes, files,... your
module leads to those strange red entries as mentioned before. I
think you had good reasons to do so - could you explain them?
Maybe we together find another solution that is cleaner and
doesn't need that double-storeing thing.
Then, there is amissing featurein my opinion: Dependencies to
other modules. Could be an easy array, but would often help a lot.
And - i thinkthats the worst feature - there is that
self-deactivating: Is see your idea but i think it breaks more
than it helps.
We often develop modules (like many other agencies as well i
guess) that keep lots of helpers for one project. So in that
module you have an extension for oxarticle, for details, start,
for the checkout,... so now it comes to the point that something
is broken in some special cases let's say in the checkout for
example. Now the shop deactivates the module and baaammm
oxarticle, details, start,... will also be broken in ANY way!
Hope to start a fruitful and constructive discussion.
Best,
Joscha
--
//-
Joscha Krug
marmalade.de e.K.
www.marmalade.de http://www.marmalade.de/ k...@marmalade.de
Re: [oxid-dev-general] Full category tree in azure theme?
Hi,
thanks for your answer.
As a collegue of mine found out, you only need to add this line
[{assign var=categories value=$oxcmp_categories}]
at the start of the azure category tree termplate and it works.
regards
Gernot
Am Fri, 30 Nov 2012 17:29:59 +0100
schrieb OLIGOFORM GbR i...@oligoform.com:
isn´t it possible with a little smarty like this:
[{assign var=homeSelected value=false}]
[{if $oView-getClassName() == 'start'}]
[{assign var=homeSelected value=true}]
[{assign var=expandedCategory value=$oView-getActCategory()}]
[{if $expandedCategory $expandedCategory-getExpanded()}]
[{assign var=homeSelected value=false}]
[{/if}]
[{/if}]
ul id=olg_navigation class=sf-menu sf-vertical sf-js-enabled
[{assign var=categories value=$oxcmp_categories}]
[{defun name=tree categories=$categories level=$level}]
[{assign var=deepLevel value=$deepLevel+1}]
[{assign var=oContentCat
value=$oView-getContentCategory() }] [{foreach from=$categories
item=_cat}] [{if $_cat-getIsVisible() }]
[{* CMS category *}]
[{if $_cat-getContentCats() $deepLevel 0 }]
[{foreach from=$_cat-getContentCats()
item=_oCont}] li class=[{if $oContentCat
$oContentCat-getId()==$_oCont-getId() }] active [{else}] end
[{/if}] a
href=[{$_oCont-getLink()}][{ $_oCont-oxcontents__oxtitle-value }]/a
/li [{/foreach}] [{/if }]
[{* subcategories *}]
li class=olg_level_[{$deepLevel}]
[{if !$oContentCat $act
$act-getId()==$_cat-getId() }]active[{elseif
$_cat-expanded}]current[{/if}][{if !$_cat-hasVisibleSubCats}]
end[{/if}][{if $_cat-hasVisibleSubCats}] olg_has_sub[{/if}] [{if
$deepLevel == 1 }] a
href=[{$_cat-getLink()}][{$_cat-oxcategories__oxtitle-value}]
[{ if $oView-showCategoryArticlesCount()
($_cat-getNrOfArticles() 0) }] em
class=olg_count([{$_cat-getNrOfArticles()}])/em[{/if}]/a
[{elseif !$_cat-hasVisibleSubCats}] a
href=[{$_cat-getLink()}][{$_cat-oxcategories__oxtitle-value}]
[{ if $oView-showCategoryArticlesCount()
($_cat-getNrOfArticles() 0) }] em
class=olg_count([{$_cat-getNrOfArticles()}])/em[{/if}]/a
[{else}] span[{$_cat-oxcategories__oxtitle-value}]/span [{/if}]
[{if $_cat-getSubCats()}] ul
class=olg_level_ul_[{$deepLevel}][{fun name=tree
categories=$_cat-getSubCats() }]/ul [{/if}] /li [{/if}]
[{/foreach}] [{/defun}] /ul
it works for us with oxid 4.6.5 too.
regards,
Oliver
Am 30.11.2012 um 16:29 schrieb Gernot Payer:
Hi,
according to this thread
http://forum.oxid-esales.com/showthread.php?t=14350 having the full
category tree in the left sidebar is still possible with a few
config options in the basic theme. This works, we tested it.
Unfortunately there seems to be no easy way to have the same
functionality in azure theme (or in themes derived from azure). We
added all necessary options from basic to azure, but there was no
change.
A few more tries (options in config.inc.php, overriding config
variable checks via module) didn't help either.
So my question, is there any way to get that functionality back?
Where is the location where azure and basic diverge? I mean, the
backend stuff is the same, so there must be a significant
difference elsewhere.
regards
Gernot
--
***
Dipl.-Inf. Gernot Payer
Software-Entwickler
shoptimax GmbH
Guntherstraße 45a
90461 Nürnberg
Amtsgericht Nürnberg HRB 21703
GF Friedrich Schreieck
Tel.: 0911/25566-17
Fax: 0911/25566-29
pa...@shoptimax.de
http://www.shoptimax.de
***
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
O L I G O F O R M GbR
Web. Design. Entwicklung gute Beratung
Ulestrasse 1
06114 Halle/Saale
Telefon +49345694931-70 | Fax -63
Mo-Do 9:00-16:00 Uhr ::: Fr 9:30-15:00 Uhr ::: Mail 24 Stunden
eMail bu...@oligoform.com
Web www.oligoform.com
Um eine zügige Bearbeitung Ihres Anliegens zu gewährleisten,
antworten Sie bitte immer an bu...@oligoform.com _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _
::: BITTE BEACHTEN :::
Senden Sie uns Passwörter nicht per E-Mail und nur nach vorheriger
Absprache! Wir teilen Ihnen dann mit, wie Sie uns diese übermitteln
können (Fax, SMS, Telefon…)!
::: Think before you print :::
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
--
***
Dipl.-Inf. Gernot Payer
Software-Entwickler
shoptimax GmbH
Guntherstraße 45a
90461 Nürnberg
Amtsgericht Nürnberg HRB 21703
GF Friedrich Schreieck
Tel.: 0911/25566-17
Fax: 0911/25566-29
pa
[oxid-dev-general] Full category tree in azure theme?
Hi, according to this thread http://forum.oxid-esales.com/showthread.php?t=14350 having the full category tree in the left sidebar is still possible with a few config options in the basic theme. This works, we tested it. Unfortunately there seems to be no easy way to have the same functionality in azure theme (or in themes derived from azure). We added all necessary options from basic to azure, but there was no change. A few more tries (options in config.inc.php, overriding config variable checks via module) didn't help either. So my question, is there any way to get that functionality back? Where is the location where azure and basic diverge? I mean, the backend stuff is the same, so there must be a significant difference elsewhere. regards Gernot -- *** Dipl.-Inf. Gernot Payer Software-Entwickler shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Amtsgericht Nürnberg HRB 21703 GF Friedrich Schreieck Tel.: 0911/25566-17 Fax: 0911/25566-29 pa...@shoptimax.de http://www.shoptimax.de *** ___ 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
Hi Marco, thanks for the links, this looks really promising. I did a quick tour through the scripts and template files and these new changes definitly go in the right direction. Expecially the new widget classes are really nice. And here I have a feature request for another widget class: oxwTopArticleList! At the moment the top products functionality is still fixed in oxUBase and is still called getTop5ArticleList(). And this limit of five articles is still implicitly hardcoded. Yes, oxarticlelist::loadTop5Articles can take a limit parameter, but no current caller uses it. As a widget this feature could be used much more flexibly (e.g. not only in the sidebar) and finally the limit might be configurable. Either as a oxid_include_widget parameter or somewhere in the admin settings. I'm looking forward to it! :) grüße Gernot Payer Am Thu, 11 Oct 2012 19:54:27 + schrieb Marco Steinhaeuser marco.steinhaeu...@oxid-esales.com: 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 -- *** Dipl.-Inf. Gernot Payer Software-Entwickler shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Amtsgericht Nürnberg HRB 21703 GF Friedrich Schreieck Tel.: 0911/25566-17 Fax: 0911/25566-29 pa...@shoptimax.de http://www.shoptimax.de *** ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Module dependencies in metadata.php?
Hi, I'm sorry, but that's not what I was talking about. Imagine an extension A which extends oxArticle with a new method a(). Extension in this context means a directory containing module files and a metadata.php file. Now imagine a second extension B which extends some other objects and uses oxArticle::a() from extension A. What we now need is some way to declare that extension B depends on extension A. I hope this explanation makes it clearer. grüße Gernot Payer Am Fri, 5 Oct 2012 13:59:42 +0300 schrieb Rimvydas Paskevicius rimvydas.paskevic...@oxid-esales.com: Hi, Yes. If few different modules extends same oxid class, simply use dragdrop in extended modules list and make sorting according your needs. Sorting extensions is same as was before using oxclass=myclass1myclass2. Rimvydas -Original Message- From: Gernot Payer Sent: Friday, October 05, 2012 11:23 AM To: dev-general@lists.oxidforge.org Subject: [oxid-dev-general] Module dependencies in metadata.php? Hi OXID Devs, is there a way to declare dependencies between modules? E.g. we have a few standard extensions for B2B shops and further customisations are often based upon these extensions. So it would be very useful if you could put such dependencies into metadata.php. Unfortunately I found nothing in the documentation. Is there a way? Or is it at least planned to include such a feature? grüße Gernot Payer -- *** Dipl.-Inf. Gernot Payer Software-Entwickler shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Amtsgericht Nürnberg HRB 21703 GF Friedrich Schreieck Tel.: 0911/25566-17 Fax: 0911/25566-29 pa...@shoptimax.de http://www.shoptimax.de *** ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Module dependencies in metadata.php?
Yes, exactly. And furthermore this should check, that you don't deactivate an extension on which other extensions depend. grüße Gernot Payer Am Fri, 5 Oct 2012 14:24:36 +0300 schrieb Rimvydas Paskevicius rimvydas.paskevic...@oxid-esales.com: So I understand what you need is you cannot install module B if module A is not installed? In this case there should be something like system requirements check before installing a new module. Currently oxid does not has such check, but I guess in future we will implement this as this this quite important feature. Rimvydas -Original Message- From: Gernot Payer Sent: Friday, October 05, 2012 2:17 PM To: dev-general@lists.oxidforge.org Subject: Re: [oxid-dev-general] Module dependencies in metadata.php? Hi, I'm sorry, but that's not what I was talking about. Imagine an extension A which extends oxArticle with a new method a(). Extension in this context means a directory containing module files and a metadata.php file. Now imagine a second extension B which extends some other objects and uses oxArticle::a() from extension A. What we now need is some way to declare that extension B depends on extension A. I hope this explanation makes it clearer. grüße Gernot Payer Am Fri, 5 Oct 2012 13:59:42 +0300 schrieb Rimvydas Paskevicius rimvydas.paskevic...@oxid-esales.com: Hi, Yes. If few different modules extends same oxid class, simply use dragdrop in extended modules list and make sorting according your needs. Sorting extensions is same as was before using oxclass=myclass1myclass2. Rimvydas -Original Message- From: Gernot Payer Sent: Friday, October 05, 2012 11:23 AM To: dev-general@lists.oxidforge.org Subject: [oxid-dev-general] Module dependencies in metadata.php? Hi OXID Devs, is there a way to declare dependencies between modules? E.g. we have a few standard extensions for B2B shops and further customisations are often based upon these extensions. So it would be very useful if you could put such dependencies into metadata.php. Unfortunately I found nothing in the documentation. Is there a way? Or is it at least planned to include such a feature? grüße Gernot Payer -- *** Dipl.-Inf. Gernot Payer Software-Entwickler shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Amtsgericht Nürnberg HRB 21703 GF Friedrich Schreieck Tel.: 0911/25566-17 Fax: 0911/25566-29 pa...@shoptimax.de http://www.shoptimax.de *** ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
[oxid-dev-general] Pictures with uppercase extensions not working. But why?
Hello dev list, I stumbled upon a fact which slightly baffles me, as I can find no reason in the code for it being so. If you put an image file image.JPG into the master/product/1 folder and put the appropriate OXPIC1 = image.JPG into the DB, there will be no image being generated. At first glance this is no suprise, because why would you code for stupidly named images, but I checked the code and so far found not a single line of code that actually cares about the file extension. There is only one file type check, which is done by gdlib. But this one correctly recognizes a JPEG file, I tested it on the commandline via php -r Does anyone know where the file extension is actually relevant in the picture generation code? regards Gernot Payer -- *** Dipl.-Inf. Gernot Payer Software-Entwickler shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Amtsgericht Nürnberg HRB 21703 GF Friedrich Schreieck Tel.: 0911/25566-17 Fax: 0911/25566-29 pa...@shoptimax.de http://www.shoptimax.de *** ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Pictures with uppercase extensions not working. But why?
Hi Jürgen,
unfortunately this does not help. I already had that idea, but this
config variable is only used in other parts of the shop.
regards
Gernot Payer
Am Wed, 30 May 2012 10:47:56 +0200
schrieb Hans Jürgen Fricke h...@narendra.de:
Hi Georg,
this may help:
In file config.inc.php (root-folder) in line 40 you find:
$this-aAllowedUploadTypes = array('jpg', 'gif', 'png', 'pdf',
'mp3', 'avi', 'mpg', 'mpeg', 'doc', 'xls', 'ppt');
The file config.inc.php is write protected.
Regards
Hjue
--
***
Dipl.-Inf. Gernot Payer
Software-Entwickler
shoptimax GmbH
Guntherstraße 45a
90461 Nürnberg
Amtsgericht Nürnberg HRB 21703
GF Friedrich Schreieck
Tel.: 0911/25566-17
Fax: 0911/25566-29
pa...@shoptimax.de
http://www.shoptimax.de
***
___
dev-general mailing list
dev-general@lists.oxidforge.org
http://dir.gmane.org/gmane.comp.php.oxid.general
Re: [oxid-dev-general] Pictures with uppercase extensions not working. But why?
Hi Björn, thanks for the hint! I really didn't think about looking into .htaccess. So instead of providing images as static content, they are now only delivered via script (core/utils/getimg.php). Good to know. Thanks again! regards Gernot Am Wed, 30 May 2012 11:01:22 +0200 schrieb WBL Björn Lange oxid...@wbl-konzept.de: Good Morning Gernot, Am 30.05.2012 10:41, schrieb Gernot Payer: Hello dev list, I stumbled upon a fact which slightly baffles me, as I can find no reason in the code for it being so. If you put an image file image.JPG into the master/product/1 folder and put the appropriate OXPIC1 = image.JPG into the DB, there will be no image being generated. Maybe it is: oxDynImgGenerator::_getImageType() - /.*\.(png|jp(e)?g|gif)$/ does not like uppercase extensions. And if this regex can't match, _generateImage does not call the _generate(Png,jpeg,...) methods. Regards, Björn -- *** Dipl.-Inf. Gernot Payer Software-Entwickler shoptimax GmbH Guntherstraße 45a 90461 Nürnberg Amtsgericht Nürnberg HRB 21703 GF Friedrich Schreieck Tel.: 0911/25566-17 Fax: 0911/25566-29 pa...@shoptimax.de http://www.shoptimax.de *** ___ dev-general mailing list dev-general@lists.oxidforge.org http://dir.gmane.org/gmane.comp.php.oxid.general
