bAum

*bump*

Jigoshop is consistently slowing down page load times; about +1 second on my server. Switch it off, speed goes up, switch it on, speed goes down.

Compared to WP E-Commerce, its fast as lightning though.

There shouldn’t be anything in Jigoshop itself which is causing it to load pages slowly – certainly we haven’t experienced any problems during testing or had anything similar reported.

Yeah; the Jigoshop devs did not even catch the bug that the pagination on the product page (in the admin section) did not work. That tells me that they are testing with shops having 30 products tops. That’s just pathetic.

It’s a shame that the e-commerce plugins out there are all so poorly engineered.

Here is the patch (against version 1.0)

*** ajax-event-calendar.php	Sun Oct  9 15:15:14 2011
--- ajax-event-calendar-patched.php	Sun Oct 30 10:40:09 2011
*************** if (!class_exists('ajax_event_calendar')
*** 801,807 ****
--- 801,810 ----

  					if (!$row->allDay) {
  						$out .= ' ' . $row->start_time;
+ 					} else if($row->end_date != $row->start_date) {
+ 						$out .= ' — ' . $row->end_date;
  					}
+
  					$out .= '</span>';
  					$out .= '<span class="fc-event-title">' . $this->render_i18n_data($row->title) . '</span>';
  					$out .= '</li>';

of course; your calendar app is great.

Just a thought: whenever I need to create dynamic files with no .php extension, i just create a folder with the filename and an index.php inside. This is totally transparent for the user-agent that downloads the file. Moreover, since css files are heavily cached by modern browsers, it shouldn’t be a to much of a scalability problem to generate the same file over and over on demand..

oh; and thanks for the kind response

I found a solution: you have to actually change a color in the existing categories before you save it. Just saving won’t do anything.

Nevertheless, this stuff should not break because of a simple update.

Thanks ItsGC, this works for me! Unfortunately, it’s a bit unclear when reading it here in the form as & # 0 3 9 ; is rendered ‘.

That particular piece of code was only changed with WordPress 3.0. In WP 2.9.2, this piece of code looked as follows:

if ( defined('ABSPATH') )
	require_once(ABSPATH . 'wp-load.php');
else
	require_once('../wp-load.php');

This would have worked as well.

The thing is that the __FILE__ constant in the above snippet equals ‘admin.php’. Using dirname() only makes sense if __FILE__ returns a path, which it doesn’t (at least not on my server).

So unless my server/php is at fault for returning ‘admin.php’ instead of ‘/www/…/admin.php’, this *is* a bug.

*bump*

In my case, WP 3.1.2, it was due to a bug in wp-admin/admin.php

at line 30 it says

require_once(dirname(dirname(__FILE__)) . '/wp-load.php');

which could not possibly work

I changed it to:

require_once('../wp-load.php');

and it works now.