Messages

after that,,I read some text like this,,

/....../....../public_html/toko-online/core/lib/menu_control_storefront.php</b> on line <b>24</b>

so,,what must I do??? 

This is not really asking you to be completely telepathic.  Just a lot .

What  method would generate a call to core/lib/menu_control_storefront.php ??

David

RE the php.ini file.

On some hosts, this will be processed, and the settings respected.  On others, it will not be.

This depends on how PHP is installed and configured.  Unless this setting is in a php.ini file in the Abantecart distribution, it is NOT an Abantecart bug, but a hosting issue which needs to be addressed by either reconfiguring your hosting account, or getting your host to do so for you.

If you do find a 12KB limit set in the distribution, I would report that as a bug immediately..

David

In the absence of a reply since December 13th, it appears unlikely we'll get much more information on this.  But considering the dot paths seen in the error message supplied some further investigation would seem to be necessary..

Where would that portion of the file path come from ??

David

you mean "stores" as different hosts or 2 stores on the same engine and same host(multistore)? For multistore described feature not needed because every order have store_id. You can separate orders easy.

I like this consistent approach better than offering alternative labels, as it makes for more consistent path management when working sales support and fulfillment.  There always seems to be some expectation that the selected label will also work in a URL - and when it doesn't, then you waste time....

David

I look to match the use of the content to the structure of the presentation.

Blogs are optimized around a journal or log type presentation - reverse chronological order is the primary presentation order.  This is not a terribly useful basis for browsing.

I know that it has become popular in recent years to consider search an adequate substitute for good in-site indexing (ie well structured navigation) but this is just false.

In short, a blog is a great place to build a development or operations "COOKBOOK" - but not a manual.

David

If an extension is distributed with the cart, its requirements should be included with the cart requirements.  The fact that it is a LIMITED requirement can be handled with appropriately built content.  "Some components may also require:".

When we advertise that we specifically support a given cart, it means that we will pre-install ALL requirements for the cart and its most popular extensions, and are prepared to install any additional requirements expeditiously.  We definitely watch that list..

David

Given the recent post expressing some concern over marketing Abantecart, I thought a few comments on how white labeling can affect a projects marketability would be in order here.

Perhaps one of the greatest strengths of an Open Source approach to development is the extent to which a project can benefit from community driven viral marketing.  Such marketing offers great potential cost savings in terms of both labor and cash expenditures - which can seriously improve ROI for the participating project members and core stake holders in the community.   But, such marketing is never cost free, or without difficulties.

Two big challenges in marketing this way include the ability to maintain consistency and clarity in the messaging carried out in the course of decentralized marketing activities.   Another is achieving sufficient concentration of messaging to generate a constant flow of web traffic to all concerned.

Whether to white label, and how white labeling is done will have a great deal of impact on how successful a project is in meeting those challenges.

Something to think about..

David

FYI:

The list of requirements published at  http://www.abantecart.com/ecommerce-documentation/20-installation  does not include a SOAP extension dependency....

David

I suspect this is the update for which I've been waiting.

Will try it out pretty soon.  Thanks!

David

Don't use wordpress.

What you have is fine, application wise.

You need to settle on a document structure, then stick with it.  The current site appears to start to chunk the content down, then stuff the content into big pages.  I could rebuild that, and would be happy to help.

Possible concept:  Start a 2nd such such wiki site to handle building new documentation before each release.  Then export the content and import it into the live site to update.

David

This would seem to be much simpler than an FTP based approach, but I would ask, for what value of simpler, and at what cost?

The FTP based approaches I've used before involve a file base name being fed into the database with the object to which it should be attached.  The relationship is simple and clear.  While it requires some additional knowledge on the part of the store operator it allows the image data to be uploaded at the same time as the basic product or category data with no knowledge of database relationships whatsoever. 

In the course of using this approach, the operator must gain some awareness of how the file system works.  As files are uploaded, they periodically are exposed to the listing of directory contents - thus affording some review of the files present.  In fact, I've managed to discover the presence of hack files because of this approach.  It is one element of a layered approach to site security.

I have also used in in both batch and single item processing as a developer and store operator with minimal investment in time expended.  SQL selection is straightforward for developers, and completely irrelevant to the store operator.

The approach currently implemented in Abantecart does appear to reduce the need for FTP operations.  Nice thing from a security standpoint is that it does not require the store operator to possess credentials, thus limiting their access to the store code.  But, neither does it afford the file system review opportunities using FTP brings to the table.  Bit of a wash there.

It does however, require much more awareness of database structure and content in the course of batch processing using import files, as well as some significant increases in data storage and processing in the course of attaching resources previously loaded into the database to specific objects.  So, we're increasing web server load and server resource use to get this freedom from FTP as well as more complex data management system education requirements.

Additionally, the more 'primitive' approach allowed the store operator to control the image names used in image urls, which the current Abantecart system does not.  As the image name is used in calculating context scores by various search engines, this is an impediment to optimization in search performance.

Does the ability to control alt tag content which Abantecart offer overcome these changes?  Only time and observation of active live sites will tell......

Great!

Glad that fixed the issue.

David

This type of issue is the bane of off-site "hosted page" type payment platforms like Paypal - it is incredibly common.

Begin with checking your paypal account setup.  Is IPN configured??

If not, you're unlikely to get notifications.   At minimum, set IPN to be enabled, with no further setup.  Generally a good Paypal module will send the appropriate return URL's in the information packet - but can't force IPN or PDT to be enabled on its own.

Sounds like you get no incremental updates from your provider at all, and perhaps use their content and pricing without modification.

Have you considered using a Diff tool like WinMerge to compare their latest update file with the previous update to cut the data processing down to smaller chunks??

David

The short answer to your last question is no.

The longer but more accurate answer is yes, but not without consequences, and not in any way which is likely to please anything like a majority of any community.

Speaking to this as a developer who has worked closely with store owners on this issue in the past, a few of the issues involved include:

1. Need for unique indexing id's per product which are next to impossible to supply across multiple systems such as your store and your suppliers stores.
2. Impossibility of guaranteeing that two suppliers won't use the same 'model number' for different products.
3. Need to avoid creation of duplicate entries for the same product with consequent duplicate URL"s.
4. Need to assure proper generations of relationships between media files and various products.

These are just a few of the many issues involved here.  30 minutes is a significant improvement over the time required to manually enter 9200 products...

David