Ping... we're looking to switch from OpenX to be better integrated w/ joomla & our Magazine component, but can't commit until the Community Builder integration is in place. A tentative release date for Ad Agency 2.0?

Merav,

Could one of you developers take a moment and walk us thru that author/user integration? It's very confusing how the tables are linked, and I'm getting all sorts of odd errors as various editors tweak content either using the content manager or the magazine module.

Specifically, I'm having trouble understanding how a given article is associated with a jos_user entry -- while at the same time having an entry in the jos_magazine_users table. As far as I can tell, you're using the created_by_alias (text field) in the jos_content table to make the link, but that's pretty tenuous as it can be edited (inadvertently) in the content manager. Example: a well-meaning sub-editor goes in and adds a title in the alias field, so now the alias reads "Bob Smith, MD" -- and hey, presto, the association back to the magazine has been severed.

It's also not clear why the created_by field itself isn't simply used -- if you insist that a magazine author has an entry in the jos_users table, then why not simply use that ID directly? But again, I'm having a hard time following the logic, so it would be very helpful if you could do a quick 101 of the schema and thoughts behind the structure.

I'd like mod_current_articles to appear only on article pages, not on the main magazine page itself (where I already have a more detailed breakdown of the issue's contents). But since articles are tagged with the itemID of the magazine itself, I'm having a hard time figuring out how I spec the exception of the main magazine page for the module's display parameters. Anyone?

Richard,

Yes, both in the drop-down for the content wizard's "add article" module, as well as the general articles manager.

In the wizard it would be great if there was way to set the issue for all slots in one go, so you don't have to go in and select for each article being added -- typically, if you're doing them in a batch, they're all going to be for the same issue anyway.

In the admin module it would be extremely helpful if the issue drop downs could follow the ordering set in the issues manager instead of defaulting to alphabetical.

We've got 10 years of monthly issues, ordered reverse chronologically, but when we're editing, the drop down will show "April 1999 -- April 2000 -- April 2001... August 1999..." etc. instead of "January 1999 -- February 1999... January 2000". It's a pain in the neck for my editors to constantly have to scroll around to find the latest issue that they're working on because it ends up waaay down the list of 80 or so issues.

In the issue manager of 2.1.05 you provide a link to view the various pre-designed templates, but the link (http://www.ijoomla.com/Joomla_Magazine/FAQ_-_Version_2.0/All_Layouts/) is dead -- it just goes to the main ijoomla homepage.

It should go to http://www.ijoomla.com/images/stories/v20/all_layouts.gif.

Ricardo, thx for your reply. Please see my Q here: http://www.ijoomla.com/option,com_smf/Itemid,6000/topic,168.0/ as to why exactly the mambot is sold separate from the store, since it appears to provide a significant part of the functionality and does not work without the store.

I'm trying to understand the rationale behind the split between the digistore and the digistore mambot. Specifically, I'm trying to understand why the mambot isn't released as part of the functionality of the store? There's something odd about paying $80 for a full-blown store, but then having to pay an additional $50 for the additional functionality provided by a single mambot. While the store certainly works fine without the mambot, the mambot does not (as far as I can tell) work without the store, so essentially you're offering two versions of the store.

There are many features of the store that I will not be using that I would have preferred not to pay for in order to spend the money on the functionality that I really *do* need (the mambot). So, if you're going to go a la carte with functionality and split off things like the mambot, why not go all the way and let us pick and chose which modules/mambots/functions we want in our package?

It would be great if you could find a way in a future release to get away from the rather clunky "point to an image that you already uploaded to the images folder to use with this product" protocol.

I build by joomla installs with the JCE editor w/ the extended image manager, so my clients are used to simply uploading their images in the copy when they need them, resizing them on the fly, generating the thumbnail automatically, etc. Telling them to now go back to using the (painful) media manager to first upload their product images, and then to go back to the product editor to add the iamge to the product is a bit of a step in the wrong direction.

I'm just implementing my first digistore, so bear with me if this is obvious to everyone else.

My client would like to feature a product from the shop on the homepage with a small image + text + price teaser; the link off the teaser can go to the product description inside the shop. The cart module has an option to set a default category, but as far as I can tell, all it'll display on the front end is the big "buy now" button. Is there a way to automatically generate a teaser for a product from the cart -- something akin to the way the magazine component will allow you to pull a feature article to the homepage?

I would second that suggestion; I have a client that would be very interested in a well-built bridge between a digistore and an existing events calendar (a substantially modified version of jEvents), which would provide event registration + payment functionality. I hope you will consider it: from a developer/client point of view yours would be a very welcome alternative to the current *very* expensive pay-per-transaction options from the likes of active.com.