GetSimple Support Forum

Full Version: Release v3.2.0 beta
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
Things to specifically test.

The new plugins toggling
Wide theme
New config definitions, make sure they all work.
Plugin compatibility of course
(2012-12-15, 02:57:18)shawn_a Wrote: [ -> ]Things to specifically test.

The new plugins toggling
Wide theme
New config definitions, make sure they all work.
Plugin compatibility of course

I don't know what the Plugin toggling does.


The wide theme, is this purely so editing window is larger on wide screens?


Plugins:

When activating both the plugins Simple input Tabs and Small Plugin toolkit, I get a white screen with this error:

Quote:Fatal error: Cannot use string offset as an array in ../plugins/small_plugin_toolkit.php on line 192
When I only activate one, I don't get the error
This is not the case in the stable version. I will make a report in th thread as well.

.. hm, I'm senior editor now.
Wide makes the entire admin wide, maybe too wide, there is no max width.
I find it useful, been using it for a year now.

Any news on the plugin issue, sounds like a plugin issue though.

Plugin toggling is now much cleaner, synchronous, one at a time, with obvious ajax indications.
small esthetic bug, sitemap text showing across the screen, over other items
http://i.imgur.com/ZtXpb.png
Looks like an old issue, not new.
@shawn_a, that's happening with 3.20b, using the old 3.12 everything is fine.
Oh my bad, hmm, you are right.
released
3.2.0b2

Fixes for
sitemap display
and white screen on empty log view
Updated to b2, the sitemap display issue is fixed. But i noticed that the included jquery version in admin\template\js as jquery.min.js is an old version (jQuery v1.7.1) current release is v1.8.3
Same for jQuery UI 1.8.17 that could be updated to 1.9.2

also admin/inc/plugin_functions.php needs to be updated :

Code:
[quote]/**
* Register shared javascript/css scripts for loading into the header
*/
if (!defined('GSNOCDN')){
    register_script('jquery', '//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js', '1.7.1', FALSE);
    register_script('jquery-ui','//ajax.googleapis.com/ajax/libs/jqueryui/1.8.17/jquery-ui.min.js','1.8.17',FALSE);
} else {
    register_script('jquery', $SITEURL.$GSADMIN.'/template/js/jquery.min.js', '1.7.1', FALSE);
    register_script('jquery-ui', $SITEURL.$GSADMIN.'/template/js/jquery-ui.min.js', '1.8.17', FALSE);
}
register_script('fancybox', $SITEURL.$GSADMIN.'/template/js/fancybox/jquery.fancybox.pack.js', '2.0.4',FALSE);
register_style('fancybox-css', $SITEURL.$GSADMIN.'/template/js/fancybox/jquery.fancybox.css', '2.0.4', 'screen');

/**[/quote]
We didn't plan on updating any dependencies until next major release
Is there a particular reason?
wow no one is excited about a new release ?
I am Smile
But there's no option to show my appreciation (you should consider adding some kind of kudos extension to forum's script).
I'll test it surely in next couple days.
(2012-12-22, 14:46:24)shawn_a Wrote: [ -> ]wow no one is excited about a new release ?

I am very excited to see 3.2 almost done Smile
I did a stress test using blitz.io to check new 3.2 caching and my nginx server-side fastcgi caching rules (based on http://get-simple.info/forums/showthread...0#pid24930 )

here are the very impressive results. It looks like GS is able to sustain a really heavy load.
http://i.imgur.com/FyZjn.png

21,804 HITS WITH 0 ERRORS & 0 TIMEOUTS ...AWESOME!
(This rush generated 21,804 successful hits in 1.0 min and we transferred 87.88 MB of data in and out of your app. The average hit rate of 350/second translates to about 30,253,906 hits/day.
The average response time was 336 ms.)
Had you done this same test with 3.1.2 ?
It would be interesting to compare with 3.0 too...
@Carlos, i did a few tests but not comparable (different config, different server etc). Can't compare. But i'm quite confident 3.2 is faster than previous version under heavy load. And, most important, it looks like it's able to deal with lots of visitors without slowing to a crawl. If that's important to prepare a review of 3.20 final i can prepare a test bed with one default wordpress site, one default getsimple 3.0 and one default 3.2 to do some stress test and comparison.

I still have one really strange problem about one thing i can't achieve. I have 2 sites on the same server, with the same config, one without plugins (an old static site i ported to GS) and a small brochure site with just 1 plugin.

first one gets cached perfect into the browser, so that after a page is loaded i can get back to the same page and (chrome developers tools / network confirm) the page gets served from browser cache, like proper cached images and other static resources. The other website (only difference that comes to mind is that's using p01-contact plugin) always generates a request to the server. Looking into the headers everything is set correct (expires etc) *BUT* only on the second website there's an additional response header "Pragma:no-cache" that i suppose prevents complete client-side caching of any page.

ne1 knows where that additional "Pragma:no-cache" header is set, why it's present only on some sites and what can i do to prevent it from appearing if i want to enable client side caching on my sites? (pm me if you need the 2 websites address)
We have not made any major optimizations to 3.2 but have made some significant ones. and removed some significant overheads. We probably shaved 100ms off all requests.

We plan on refactoring for 3.3.0 with some major optimizations in many very low level functions. Hopefully it will all add up to another boost in performance.


I would assume a blog plugin or similar would use no-cache, and maybe implement it incorrectly so that you see its affect on all pages. Man I haven't even begun to do client profiling on my sites to catch these issues and optimize caching. If you have any suggestions, i would love to hear them.
I have empty options in Edit Theme, only Default Template is visible, switched back to 3.1.2 and it's working

would be fine, if line height of plugins won't change after enable/disable
@shawn_a the only plugin i run in the site not properly caching is p01-contact, which doesn't seem to directly set the no-cacheheader. But (there's always a but) that plugin set a session cookie, and that's the only other difference i spotted between the cachable and non cachable site.

Add to that that the regular p01-contact has bug (because of user.xml) that exhibits on every page of the site. I mean, whatever page of my website i visit a line in error log gets written notifying of the error in that plugin not finding user.xml. I manually fixed that bug, but why do i get the error on the home page also?

i still don't know if the session cookie that p01-contact sets is the cause for the added pragma:no-cache, but i'd like have a more resilient getsimple with better plugin isolation so that a faulty plugin (i'm still looking for a contact plugin that allows me to easily create a nice ordered multi-colon form layout) doesn't interfere with other pages.
Maybe coding guidelines are sufficient, but i think something should prevent that a contact form plugin disables caching even on the home page. And that could easily shave many ms when a user navigates back to a page he already visited.
(2013-01-05, 02:30:28)marrco Wrote: [ -> ]@shawn_a the only plugin i run in the site not properly caching is p01-contact, which doesn't seem to directly set the no-cacheheader. But (there's always a but) that plugin set a session cookie, and that's the only other difference i spotted between the cachable and non cachable site.

PHP will by default automatically set the no-cache header, if there is a session, see e.g. http://php.net/manual/en/function.sessio...imiter.php, otherwise the page (containing possibly information only available for the current visitor) might be cached by caching proxies, etc.
Yeah sessions should be avoided for guest access, thats alot of overhead in addition to the aformentioned issue.

morvy
Are you installing the beta over another install ? Make sure you are clearing your cached files, stylesheets are cached.
I am not sure i understand your issues.
clean install :/ on usbwebserver 8.5
@mvlcek ok, thanks for confirming me that. And that makes sense. What's wrong is that p01-contact that i use just on the 'contact' page causes the no-cache header on every page, including the home page.

I don't know if there's an easy solution to that issue, or a better way for a plugin to have just a single page not cachable, nor I know the reason p01-contact developer decided to have that session cookie set, but for many small "brochure websites" avoiding those problems could give an additional performance gain.

(not a rant, GS is great, much faster that WP and other cms, I was just testing nginx rules with 3.2 beta and couldn't achieve client side caching on a site, so after some experimenting i found this issue. Whoever thinks gs is slow or heavy on the server just look at the stress test i run this morning)

(2013-01-05, 02:51:07)shawn_a Wrote: [ -> ]Yeah sessions should be avoided for guest access, thats alot of overhead in addition to the aformentioned issue.

ok, so now there's an additional problem. One of GS most used plugin is not so good. And creates issues on every page not only on the one it's used.

Even small brochure (mostly static) websites often need a few plugins (contact/feedback, google maps, photo gallery, slider). I think at least those must be of very high quality. Plugins quality is very important for the final result.

Maybe not part of the core, but a simple-contact, simple-maps and simple-gallery plugin could be maintained/suggested/endorsed by the developers so that a user can be sure to have a well coded, fast and secure website.
(2013-01-05, 03:02:06)morvy Wrote: [ -> ]clean install :/ on usbwebserver 8.5

What browser? What does the code look like? There are obviously entries in that list they are just blank.
Pages: 1 2 3