Frog CMS - Frog 0.9.5 RC 1 released

This post doesn't exist anymore!

Frog 0.9.5 RC 1 released

16 posts, 7 voices

Feb 14, 2009 15:45 Martijn (mvdkleijn) 651 posts	I just uploaded Frog 0.9.5 RC 1 to the site. See this blog post Please be aware that I do not recommend switching your production system to this version. There have been a number of relatively minor database changes but some major changes on the files and file structure. Also be aware that user contributed plugins will need to be updated due to some path changes. This change is minor and concerns the path with which views are called. (”../../../xyz” should become “../../xyz”) Do install a fresh copy of this release and let us know what you think.

Feb 14, 2009 16:43 ricks 486 posts	awesome, martijn. thanks for the hard work you put into this.

Feb 14, 2009 16:51 Levi 9 posts	Nice, I really enjoy Frog CMS much more than any other CMS I have worked with. It is straight forward and easy to learn, and very customizable.

Feb 14, 2009 17:29 ricks 486 posts	I’m going to start taking notes as I go through it. - default theme is still blue - default page status is still draft - roles are checkboxes instead of radios - no noticeable difference in response time on the backend at least (still very snappy) - what does 'protected' checkbox next to login dropdown do? - help hyperlink to user role documentation would be nice (on new user page) - front end urls do not work (all showing same page) if mod_rewrite option is not on - pages that require login redirect to the login page - no user registration feature - drag to copy an entire tree--nice! but it appends (copy) to title and -copy to the slug for each page in the tree (not so nice!) - skeleton plugin includes example plugin controller and views -- nice! - lowercase page parts remain lower case -- nice! - success/error messages not only fade out but disappear from the dom--very jumpy, not nice! - as before, no success message when enabling/disabling plugins - admin folder is just view-related -- nice! That’s all I noticed so far. Without creating a plugin or two I can’t really test how much easier it will be to do things without the front/back split. The only difference from the previous version I don’t like is the way the success and error messages disappear from the dom tree. The jumpiness makes it visually distracting, not very elegant. The way it was before was fine, I thought.

Feb 15, 2009 03:48 Martijn (mvdkleijn) 651 posts	Just to reply… - default theme is still blue Offcourse, since we didn’t have a good, tested new theme. (And there was no issue for it in the issue list.) - default page status is still draft But you can easily change the default in the admin screen. - roles are checkboxes instead of radios And they always will be. Its a feature, not a bug. Roles are not mutually exclusive. (nor will they be) - what does ‘protected’ checkbox next to login dropdown do? Not new in this release.. it prevents non-administrator users from altering the page. - help hyperlink to user role documentation would be nice (on new user page) Add a feature request here - front end urls do not work (all showing same page) if mod_rewrite option is not on Works on my system. Please retest and add an issue here in case it still doesn’t work. Please add all information about your system and error messages you see. - pages that require login redirect to the login page Works as designed. Once logged in, you’re redirected back to the page you tried to access. - no user registration feature Correct. Won’t be implemented either. Login stuff in Frog Core will remain light. User registration will require a plugin. (which a user is working on) - success/error messages not only fade out but disappear from the dom—very jumpy, not nice! I personally liked it because it makes for a more professional look and doesn’t make it jumpy in my opinion. Anyway, if enough people don’t like it, I’ll remove it again. You can remove it again yourself by editing the “backend” layout. - as before, no success message when enabling/disabling plugins Again, add an enhancement request if you want it. It is very difficult and time consuming for me to keep track of everyone’s wishes/desires/lusts/feature requests/issues/bugs/patches in the forum.

Feb 15, 2009 08:08 DavidCOG 96 posts	Looks excellent. Great work. :) Roles are not mutually exclusive. (nor will they be) Puzzled by that one. I’d have thought they were mutually exclusive – Admin can do everything that dev + editor can. Dev can do everything that editor can. So, no need for overlap???

Feb 15, 2009 13:38 Martijn (mvdkleijn) 651 posts	@DavidONE – You’re assuming that no one will ever decide (s)he wants a new role. That new role might have some special rights associated with it and might share some rights with for example the current “developer” role. Generally speaking, “roles” are exactly that: a role which someone executes. If they would have been mutually exclusive, they wouldn’t be “roles” but “rights”. I.e. something someone is allowed to do. A good analogy would be a website. There are multiple potential roles like the system admin and the content editor. Both roles would share one right: to edit content. But only one role would have the right to shutdown the system. In fact, Frog’s default “developer” and “editor” roles share numerous rights.

Feb 16, 2009 18:04 ricks 486 posts	About the success/error message, maybe we can put it into the same ‘bar’ that contains the title of the page (“Edit Page”, etc.). Like in the middle of that. This way it won’t take up any space and when it disappears, there’s no jumpiness or anything. it just sort of fades in and then fades out, I guess the way Gmail does it. Getting it centered may be a little tricky though… Maybe put it where “View this page” link now is and move that one somewhere else? Just a thought.

Feb 16, 2009 18:07 ricks 486 posts	Since the pages that require logging in now all use the same login page as the admin login page, would it make sense to make the login page part of the front end in terms of stylesheets? I find it sort of startling how once you are required to log in you get directed to a page that looks completely different from the rest of the site.

Feb 17, 2009 05:05 Martijn (mvdkleijn) 651 posts	Mention it as an issue on google code please.. but I agree that the “frontend” styles should be used on the login page aswell.

Feb 18, 2009 07:37 Andy 257 posts	The registered_users plugin gives you a <?php login_page() ?> function which allows you to drop that form any where on your site. That may (or may not) be something to consider…

Feb 18, 2009 13:15 Craig 76 posts	Regarding the path change required for plugins… would a solution to this be to have a global constant that contains the full directory path to the base folder regardless of version or folder structure? Thus, this code would work: `$this->assignToLayout('sidebar', new View(FROG_BASE.'/plugins/foo/views/sidebar'));` I know this still requires existing plugins to be modified; but for future-proof-ness and minimising the lines of code and complexity needed for version checking, it could be a bonus.

Feb 18, 2009 13:44 ricks 486 posts	Craig, that sounds like a good idea. I think it’s definitely not a good thing that plugins would all break when someone upgrades a Frog version. Martijn, is this the only time that this is going to happen, because of the architectural change (removing the split) in this version? Or are we going to have to expect plugins to break again when newer versions of Frog are released in the future?

Feb 18, 2009 13:54 Martijn (mvdkleijn) 651 posts	@ricks – This should be the worst of it I think. Remember that we’re still pre-1.0 but I think there should be no other major changes. My guess for now is that there will be mostly functionality added to Frog Core to improve the plugin API so developers will have to spend less time on the bones of the plugin and can spend more time on the brain of the plugin… To give you an idea of post-1.0 release behaviour: (from the Google Code wiki intended for Frog Core devs) Frog version numbering scheme Similar to most Open Source projects, the Frog project uses a numbering scheme which conforms to the X.Y.Z system. Its exact syntax is: Frog v<99>.<99>.<99> [<<RC\|SP> 99>] In filenames, spaces are replaced by underscores and the entire filename is lowercase. Possible examples of this syntax would be: frog_v1.0.0 – filename example; Frog stable version 1.0.0 Frog v0.9.4 RC 1 – normal reference; Frog version 0.9.4 Release Candidate 1 frog_v0.9.3_sp_1 – filename example; Frog version 0.9.3 Security Patch 1 What do all these numbers and letters mean? First, let us look at the <99>.<99>.<99> piece, which is divided into Major.Minor.Fix: Major version; with a major version number change, almost anything goes. Generally, features will be added, removed, changed, renamed, etc… A Major version can offcourse also contain simple bugfixes. Minor version; minor version changes should generally remain backwards compatible. Usually, features will only be added. They will only be changed if it doesn’t impact on backwards compatibility. Fix version; fix versions only contain bugfixes. Features should never be added or removed and only changed if it doesn’t affect backwards compatibility. As for the rest of the naming scheme, RC stands for Release Candidate and SP stands for Security Patch: Release Candidate; when the Frog dev team feels a version is nearing completion, they might release an RC version. This is intended to give the end user a possibility to preview the final version and will allow end users to assist in testing for bugs. Security Patch; when a security issue is reported to the Frog dev team, the team decides on the issue’s urgency. (see DevSecurityGuidelines) If the problem is deemed a high risk issue, the team may decide to release an SP. End users should always install SP versions.

Feb 28, 2009 08:38 Craig 76 posts	Regarding the flash message comment by ricks (not only fade out but disappear from the dom—very jumpy, not nice!), I’d like to suggest this is changed too (either don’t disappear, or move it to somewhere that won’t make rest of page ‘jump’). During adding pages, it’s possible to click the add icon of the wrong parent page due to the page jumping up when the flash message disappears. Bad enough when adding, but potentially disastrous if you clicked Delete.

Mar 20, 2009 16:50 ricks 486 posts	Will we have anything like wp_insert_post in 0.9.5?

Apr 3, 2009 08:24 Andy 108 posts	I like the error message being removed after 1.5secs. Its not worth the effort to remove it in the stable release and like you say…if people really dont like it then they can remove it. I suspect most, don’t really care enough to dig deep and remove it.