I am re-coding the single page login.php file to be easier to work with if anyone wants a copy.3 users found helpful
Among other things...
- I've cleaned up the code to make it much easier to follow what is going on and will be putting liberal comments in.
- I am moving the CSS out of being inlined on the page so that it does not load with every view of the login page (but is cached along with other externally included CSS which also makes it much easier to change). Admittedly it's not much but as a general rule I just don't inline CSS and such is simply not good practice.
- I am eliminating the use of the helper form as it simply gets in my way in terms of understanding what is going on in the code and makes it tougher to change it (among other things there are CSS classes in the helper functions that affect the appearance of the form. Classes that I must go digging around for to see what they are. By removing the helper functionality and putting the real HTML inside the login.php file I can see things at a glance...much easier to work with).
- I've added a block or two to allow the text in the login page to be changed at will by an end user making it more appropriate for inclusion into an existing theme in that one might want to change the text instructions to make it fit an existing site.
- I've eliminated some things like the link to go back to home. In my case such a link is superflous and distracting since the navigation menu having a clear link to Home is right above the login form.
And I have styled it to look much prettier and more Web 2.0.
I'm not done with it yet but if anyone wants a copy of my changed login form and/or to see an example of it let me know and I will gladly provide one to you (I'll need another day or so to finish it up though).
If not...no biggie. I just thought I would ask if anyone was interested as a way to contribute something back to the community here for the help I have been given in the past.
I would love to see you approach, I was thinking doing the same thing (cleaning up the mess) if time is more on my side. Still fighting demons on the block and package side. So If you are ready, please.
Instant Karma on the way for you.
I think I am going to split the reset password form out of the single login page too so that I can place a link under the login saying something like "Forgot your password? Click here to reset it." type of thing.
I don't like having a page have more than one function as it tends to confuse some end users sometimes. Just a pet peeve of mine.
Ideally one page for logging in to the administrative interface and another page for resetting the password. Much cleaner I think.
Anyway...I'll report back in a couple of days (maybe not till Monday depending on what else I have going on).
PS. I love your avatar picture Vincent :).
Still it took quite a number of hours (literally) of playing around with various print_r statements to output things, various commenting out of code to see what would happen, searching for this or that variable to figure out where it was initialized, and so forth before I came to understand the C5 login process. Can't say I understand it fully yet but I was able to understand the parts I needed to understand.
I actually went at it trying to figure out a way to avoid breaking C5's login mechanism so that I could use my custom made cache solution to achieve first page rendering at blazing speed.
Still haven't figured out a way around that problem (it's rather complicated) but along the way I figured why not rewrite the single page login, and bring it up to Web 2.0 fancy appearance standards. So...I did :).
I'll get back to you on this thread when I have it ready for public consumption.
I didn't realize that I would have to change a number of other forms to make these forms consistent on a site. Such as the user registration form for example. Working on those too.
All forms will look the same across my sites.
Yes...absolutely. No tables.
Here's a snippet...it's the code for the password reset form.
<!------------------------------------------------------------------- < Password Reset Form - used to allow an administrator or registered < user of your site to reset their password or to get a new one in < case they have forgotten it. <-------------------------------------------------------------------> <div class="round-corner-bl"> <div class="round-corner-br"> <div class="round-corner-tl"> <div class="round-corner-tr"> <form method="post" action="<?php echo $this->url('/login', 'forgot_password')?>"> <div class="fieldset"> <div class="fieldset_heading"> Forgot your Password? </div> <div class="fieldset_content">
The fieldset and fieldset_content classes do not correspond to the fieldset type HTML tags at all. I just named them that way because they do imitate their characteristics somewhat in what areas of a form are affected.
The field_container class allows me to center the fields and labels in the center of the form.
The four divs prior to the form block and ending right after are the div's that allow the rounded corners to appear around each form. With bl standing for bottom left, tr standing for top right, and so on.
I also changed the Submit "button" that was an input type HTML tag to a button tag as the button is not only easier to style but for my purposes just looks nicer across all browsers (in my opinion).
Lastly I put a <p></p> around the descriptive text enclosed by the t() function for better spacing and to line up more with good HTML coding practices in not having text that is not enclosed in some sort of block or inline-block tag.
I do have 1 comment to make, and this is really just my opinion, not criticism or fact: You might want to consider making the design a little less pretty at the expense of those non-semantic corner divs in the markup. Perhaps we have different ideas of what the primary usage of this thing is, but to me having a basic, simple-as-possible foundation of HTML/CSS to base my own custom designs off of is far more valuable than having a beautiful out-of-the-box design. I am admittedly biased here because I make my living from implementing custom designs into CMS's, but to me and the other designers and developers out there (as opposed to non-technical people building sites for themselves), having the base markup as clean as possible is ideal, and hence not having the non-semantic divs for the rounded corners would be better.
Just a thought -- the overall greatness of what you're doing here far outweighs the above comment, so if you feel that making it look good is more important than by all means keep on doing what you're doing!
PS - Super tiny simplification -- I'd change this:
<?php echo "<p>".t("Enter your email address and click button below. Your password will be reset and a new one will be sent to you.")."</p>" ?>
<p><?php echo t("Enter your email address and click button below. Your password will be reset and a new one will be sent to you.") ?></p>
I like what you are saying about keeping it simple to allow web developers to more easily adapt my approach to their own liking. For sure...that is a good thing.
Trouble is...that I am mainly developing this to make it easier for me to make modifications in line with what I want on my own web sites and not for the benefit per se of other developers.
There is little incentive for me to put in the time to make it both what I want and of maximum benefit to other developers who might not want the forms to look quite like I like them to look.
So...I have to keep on with with what I want primarily...for now.
I am toying with the idea of going all out to develop some sort of paid Add On to incorporate the changes I am making and much more (i.e. including an admin interface to allow changing of CSS values, removal of various parts like the fancy round corners, automatic placement into the various directories where things should go, automatic unistallation, etc..) but I guess I am not sure how readily such an Add On would be accepted or considered something worth paying for or even needed by the community here.
My time is very limited (though I can do pretty much what I want when I want I have a lot of pans in the fire so to speak) and I want to make sure I am spending it on something that will pan out to help me achieve the most from whatever time I do put into things.
Sharing the changes I made so far was no big deal in that I had already made those changes for myself.
Regarding an Add On for these types of changes to the system forms do you or others thing such is a good idea? Would that fly as a paid Add On? Would any form type Add On in line with the changes I have made distinguish itself from any other form type Add Ons already there sufficiently to allow mine to succeed in it's own niche?
Any input on these question from you Jordan or anyone else who likes the changes I have been making would be appreciated.
Regarding the other change you suggested. I put those paragraph tags in because generally I do that overall Jordan. I mean put text inside blocks of some sort (in this case a paragraph block). But also because spacing wise it fit with my desire for how the form should look.
I'll leave that in because it is in line with what I want for my forms (unless I go for an all out Add On with this...which I am not sure I want to do yet) but certainly anybody can strip that out easily enough I think.
To strip out the rounded corners just delete the respective DIV's and delete the corresponding CSS classes from the CSS files. Also you may have to transfer the extra margins from the rounded-corner-bl class to the form CSS itself.
In view of the extra work and the amount of code involved I may an entirely revised login.php file and it's controller as a free (or paid) marketplace add-on rather than give it all away on this thread.
But as promised the login single page form has been rewritten and if anyone wants it simply download the attached files.
OOPS. The forum won't let me upload a .php file so I changed the extension to .txt. Just change the .txt to .php and you are good to go.
Attached is a login.php (after renaming) drop-in replacement for the system login.php file (found at /concrete/single_pages/) with the login form and password reset forms redone (as well as the whole file rewritten to make it easier to follow and understand though not entirely rewritten yet).
Just copy the changed login.php file to /single_pages/ in your document root.
Also attached is the CSS I am using for my forms. Please keep the copyright notice contained inside the CSS files in place or rework it to be uniquely yours under your own copyright.
The note I put into the login.php file I changed is simply there to be explicit about my releasing it under the same MIT license as Concrete5. If my changes are rolled into the core, the note at the top of login.php may be removed and whatever changes I made can be considered as belonging to Concrete5 to do with it whatever they want.
I just want the CSS files that have a copyright notice from me to continue to have that copyright notice is all. Do whatever you want with my version of login.php.
/blocks/external_form/forms/my_contact_form.css is the main CSS file used on my forms. It does not have to be inside the /blocks/external_form/forms/directory. You can put it anywhere you like and just change the relative path to wherever you put it (relative to your document root that is).
/single_pages/login.css is a CSS file that changes a few characteristics of CSS selectors inside the main CSS file for my forms (i.e. my_contact_form.css). This CSS file resides in the same directory as my rewritten login.php file (though again you can put anywhere you like as long as you change the relative path to wherever you put such that it is accessible from inside my login.php).
The IE conditional CSS for IE...well...I'll let you figure that out on your own :) (I may release that as part of a Marketplace Add-On). That was a bear to do and I don't particularly want to give away the farm just yet.
If anyone has any questions, suggestions, or comments let me know.
I was wondering... do you think you could include the corner images? Maybe put the whole thing in a zip file and post here?
I guess I can make my own rounded corner images :( or, actually I will just use CSS3 and let it degrade "gracefully" ...
Here is a screen shot:http://justpaste.it/ds8
Here's a list of improvements:
* added php alternate syntax for easier readibility
* added ordered lists to form structure for more meaningful markup
* added styles & refactored markup for OpenID login form
* removed html rounded corner markup (now uses CSS3 border radius)
* condense all css to single stylesheet login.css
* removed arbitrary wrapper div as it's not needed
* add DIR_REL to css linked file path in case site is in subdirectory
* added custom themes/core/concrete.php template
* can now target browsers with css classess applied to html tag
* added stripped down modernizr js library for css3 feature detection (disabled but included in case anyone wants to get fancy)
* tested in all major browsers including IE6-IE9
* created ccm.default.theme.overrides.css to style page elements outside of this file's scope. (needed to style the error messages)
* added additional comments designating all form sections of login.php file.
I'm including everything in a zip file should be super easy to figure out where everything goes. I'm' hoping my work can go to the community and also make the login page more accessible to designers and developers.
Carlos thanks again for your work, my intention is to give this back to you and you can do whatever you want with it... I really was just inspired to do this ... or I couldn't sleep... well, both actually...oh yeah and by the way if you guys haven't heard Andrew Emblers EP you really need to check it out, it's available free to download from his website andrewembler.com and I swear it's the Concrete5 soundtrack, I've had it on repeat for the last 48 hours (yes I'm strange) but it's awesome you guys have to check it out it!
Anyways, please let me know what you guys think I'm pretty stoked, although I kinda like the big clunky default login screen :)
Aaron, I'm coming from the point of view of using this as an easy way to style sites I build, so towards that end I always turn on theme overrides in my config/site_theme_paths.php file and then put an overridden login.php file in my single_pages directory. But you also have a modified themes/core/concrete.php file -- how exactly is this supposed to be used? I think that's basically what would be used instead of my theme's view.php file -- is this correct? It looks like all you did was add the IE conditional classes and then pull in the ccm.default.theme.overrides.css file (and the modernizr script, which is commented out). So perhaps I don't really need this file at all and instead can just add the styles in ccm.default.theme.overrides.css to my theme's stylesheet? Or am I missing something here?
BTW, I don't see where you used any php alternate syntax (which unless I'm misunderstanding is "<?" and "<?=" instead of "<?php" and "<?php echo"). BUT I think this is a good thing when you're sharing code publicly, especially to be used by non-programmers and designers, because a lot of shared hosting environments have this feature turned OFF by default and if someone isn't familiar with it they get all these crazy errors they can't figure out.
I didn't mean short tags when I said alternate syntax... I just meant the altnerate syntax for control structures:http://www.php.net/manual/en/control-structures.alternative-syntax....
Basically just removing all curly braces from the control structures... it makes it easier for designers to get at the html, at least that is what the php docs say :)
No need for the modernizr ... but if you want to do fancy css3 stuff then it really does come in handy.
I'm curious, since I've never setup a custom theme path for my site, does this setup use your normal elements/header.php & elements/footer.php files to generate to login.php page??? If so then you're absolutely right about not needing the concrete.php file.
As for using your own theme, yeah I always want my login page to have the same skin as the rest of the site (same header/footer/sidebar/etc.), so what I do is this:
1) Uncomment all the code in the YOURSITE/config/site_theme_paths.php file. Basically make it look like this:
<?php defined('C5_EXECUTE') or die(_("Access Denied.")); $v = View::getInstance(); $v->setThemeByPath('/login', 'my_theme_handle'); $v->setThemeByPath('/register', 'my_theme_handle'); $v->setThemeByPath('/page_not_found', 'my_theme_handle'); $v->setThemeByPath('/page_forbidden', 'my_theme_handle'); $v->setThemeByPath('/download_file', 'my_theme_handle'); $v->setThemeByPath('/maintenance_mode', 'my_theme_handle');
2) Now the login form "Page Not Found", etc. will use your theme's view.php template. BUT there is one catch -- due to the way C5 is set up, you need to manually include any error messages in your view.php file. You'll find some forum threads about this which tell you to paste in a bunch of code, but I just created a separate "element" file that I include in all my sites to keep things clean:
2a) Unzip the attached file and place it in YOURSITE/elements/system_errors.php.
2b) Modify your theme's view.php file, adding this line of code:
<?php Loader::element('system_errors', array('error' => $error)); ?>
(add it just ABOVE the "<?php print $innerContent; ?>" line that should already be in there)
I've actually submitted this element to the core code so it should be included in the next version of C5 (although you'll still need to do step 2B -- explicitly including it in your view.php file).
Hope that makes sense.
This is great Jordan I was wanting to do this custom theme paths but hadn't gotten to it yet, only on my third c5 site . Now you've gone and provided something really useful... again , how do you do it? You are an inspiration for me.
Cheers to being awesome :)
Interesting addition about the errors.
I'd like to reproduce an error to see what C5 does with and without your addition. Do you know of one such error that I can reproduce easily?
Like some URL or code modification to some file that will reproduce a type of error that your file deals with?
If I miss anyone's post it's unintentional.
Compared to what you did I did nothing.
Thanks for sharing and for your contribution. I might take from what you did and add it to mine to make it better but I certainly won't just take what you did and claim it as mine. Like the changes I made it's great to see you freely giving something back to further improve the login form.
Hopefully the Concrete5 team will roll into the core whatever is good in both our contributions.
I like the look of your form better than mine. I'll have to play with it some as I am not sure I can imitate the look of yours. It seems to be of the kind that Safari might render in the nice subdued colors and nice roundedness.
Anyway thanks again!
I had this long response giving input on your approach and this forum software made it go poof! Disappear. When I accidentally hit a wrong key that caused the browser to go to the previous page.
So for now I guess I will remain silent on what I had commented on as I have no time to re-comment all over again.
Not sure I would code things as you did Mr. NiceGaius but I picked up a couple of things from your changes that I will incorporate into mine.
Thanks again for sharing.
Sucks about the post getting lost, I find the pop up box good for quick comments but when we write big posts it would be awesome if the pop up could be expanded to a full page ...AND I really would like the ability to preview my post before posting... I do like the forum for a number of reasons and I don't hate it yet :)
The way I see it we are all on the same team, please forgive me for changing anything around that doesn't work for u ...I'm just attempting to help.
There is nothing to forgive dude!
Some of my comments were positive as to things I found good in your changes and the rest were not so much negative as rather explanations of why I wouldn't do things like you did on some other changes.
Like using CSS classes with IE conditional statments vs using IE conditionals including external CSS files and other such things.
I especially liked your use of alternative PHP construct syntax. I will be using that from now on. I have been so used to the bracket syntax that I just...well...never thought of using anything else.
I like the way the give and take of contributions like we are making allows all of us to learn from each other in a way that none of us would likely be able to do alone if we did not get code input from other users/web developers.
I'll be posting a revised login.php incorporating some of your changes and including other changes I made to clean up the code even more.
People can chose whatever version of login.php they care to use. All the better for everyone to have alternatives.
If I remember correctly I made them the color they are such that to make them a different color you will have to use PhotoShop or GIMP and recolorizing them as desired (that's a bit tricky and beyond what I have time to show people how to do but the knowledge of how to do that is freely available with a little Googling and a few hours of time).
The F5F5F5 in the file names refers to the color of the corners.
In regards to your question about what to sell on the marketplace, my opinion is that foundational designer and developer tools should not be sold, whereas complete packages that can be used without modification by non-technical end-users should be sold. Part of this is just my own feelings in regards to the open source software community (basically that so many wonderful tools have been given away for free that I feel like that should be paid forward by us little guys who are standing on the shoulders of giants -- e.g. linux, apache, mysql, the php language, and of course the Concrete5 core system itself), and part of it is that I don't think there's that much of a market for developer-oriented tools. When I was building Designer Content, for example, I pondered the idea of charging for it, but realized that it's not the kind of thing that can be easily explained to people and if someone was just building a site for themselves (like a non-technical person) then it wouldn't really do them any good -- but on the other hand if I offered it for free then not only would it help people but it would make C5 a better system which in the long run will attract more users and hence create a larger market for both my consulting work as well as for the paid addons I have on the marketplace.
So I think that if you package it up nicely so someone who is non-technical can just install it and have their site improved (and it's actually solving a problem for people that you can easily explain with screenshots), then by all means sell it on the marketplace. But if it's only something that's going to be useful to a designer or a developer who's building a site for someone else, I don't think you'll get much sales.
Of course this is just my opinion -- ultimately you have to do what you feel is right for you (and it's totally reasonable to want to get compensated with money for putting a lot of time into something).
Thanks again for sharing what you have already, it is much appreciated.
Though I do wonder how many of the Add Ons are actually bought by end users who are not technical as opposed to web developers who want to save time and not recode things themselves while they develop sites for non-technical end users.
Regardless, for sure, I would not develop an Add On just for developers. At least not this type of Add On since a good web developer could code it up themselves in fairly short order.
The greatest benefit to both developer types and non-technical users would come in I think if I could develop an Add On that would do it all at the touch of a button.
Go in and create a custom login.php file in the right place, create the form with various display attributes as desired (i.e. rounded corners, no rounded corners, various colors, etc.) and so forth.
In other words a user (whether a web developer or non-technical end user) could install the Add On and then immediately go to a configuration screen where they could select whatever options they want. Then they press a button and the Add On does it all for them such that after they log out of the admin interface they now how totally redone forms in their theme rendering.
I'll have to think about this as it will take a fair bit of work.
Given the further input above do you (or anyone else) think this might make for a good Add On that would have some chance of being sold in the Marketplace? If not...it's better for me to find out now rather than tie up time doing it to only have it fall flat in not being something that others would be willing to pay something like $15 for.
Mind you I made the changes I did for my own benefit on client web sites. To make things easier on me and my clients.
But if I can make a bit of spending money on something like this that I expand and make even better and more automated in terms of the ease with which it can be installed and used...that's all the better.
I can't seem to get that form to appear. If I go into the profile to change the password I get a form that is spit out by /single_pages/profile/edit.php not the one inside the login.php file.
Could the form inside the login.php file be...well...inactive as in never used??
No CSS3 is used. All CSS is kept in external CSS files for easier maintenance.
I temporarily swiped one image from off the net to see what the form might look like and used the header images from the Concrete5 dashboard itself for the header background but I want to recreate both images in a slightly different color and to make them my very own creation rather than using someone else's.
Also attached is the latest revision of login.php incorporating some of the changes Mr. NiceGaius kindly contributed to this effort and the main CSS file.
As before login.php is named login.txt in order to get past the forum filter against uploading PHP files directly. Just rename to login.php and drop it inside /single_pages/.
Among the changes to login.php are the following:
- put all short text appearing on forms into the t() language function.
- changed from bracket use to alternate control structure syntax.
- got rid of a few superflous DIV's
- figured out why the Register link was not appearing and fixed that to where it now appears centered at the top of the screen.
- added a background gradient to all input fields.
- added a background image to the headings which also added round corners to them (again using CSS2 no CSS3 dependency involved making these changes more cross browser compatible).
- removed some superflous <p>'s as recommended by Jordan.
I still have not removed all references to the Loader form object which I want to do and I still have not changed all forms that are rendered by login.php to look like the one's in the attached images but that will come with a still later revision of login.php. There are a number of other forms that Concrete5 uses that are rendered by other files and I have to change those too.
Again pick and chose whatever you all like or don't like but hopefully the revised login.php will be of some benefit to some in it's present state of revision.
After thinking about it some I will likely develop some sort of Add On that will automate the recreation of ALL forms used by Concrete5 as well as add a contact form and install new versions of the underlying PHP files that will be much easier to understand and work with than the stock Concrete5 ones.
At least until and if any such changes are rolled into the core (but even then my Add On will provide more flexibility than any core changes will allow for as the Add On will be substantial in allowing some level of automation and customization of these forms).
Anyway for what it's worth...enjoy as a foretaste of what is likely to come with my Add On if ever get around to finding the time to actually create it :).
It will look exactly like it does in my images in IE. Without reliance on CSS3 stuff which is not fully supported in even the latest IE.
I have not uploaded the IE CSS though and will leave that as a benefit of getting the Add On I think (though I might be persuaded to upload it here at no cost if enough people clamor for it LOL). Not that it's super involved mind you but it took me two full days of work just to get things to look exactly the same in IE (at least with respect to my original form rendering though I don't expect any problems getting my latest form rendition to look exactly the same in IE since the changes mostly have to do with adding background images to various elements which IE is pretty standards compliant with).
Getting IE to render these forms exactly as I want them was one incredible pain in the rear! Let me tell you.
May I suggest inlining the css in the login.php page, which fixes the flash of unstyled content... I didn't realize this until testing on a live site and was testing in Safari 4.
I would imagine that having the css inline would be a wise default setup and when the developer enables the custom theme paths for the login page, which enables the sites theme header.php to be used for the login page then the developer can just move the inline css into the site's main stylesheet.
Hope this helps, I like the idea of having the external css file but it's really jarring to see the form unstyled on first page load.
By "inlining" do you mean using the "style" attribute on elements, or do you mean using a <style> tag? Just curious since to be W3C compliant (and for the page to validate), style tags should appear only inside the document head.
But in response to Mr. Gaius...
Inlining the CSS is definitely a no-no way around the problem. Especially if it involves someone having to muck around copying CSS here and there to get it to work correctly.
I haven't tested my changes completely on a live site yet as I am still working out changes on a local copy of Apache and have had no problem yet.
Will do live testing later when I have finished the current round of changes.
Was that site on GoDaddy by any chance? It's been my experience that Concrete5 and GoDaddy don't mix well.
Toward that end I was wondering if you all could help me determine what sections of the forms (as seen in the images both me and Mr. NiceGaius attached here) would be desirable to change from inside a Concrete5 control panel interface?
Here are some that I was thinking of...
- fieldset heading or not
- round corners or not
- if round corners, the color of those corners
- form color
- fieldset heading text
- field text
- submit button text
- color of text
If there any other things that a typical user might want to change on the forms that Concrete5 uses that are not listed above please let me know here.
Any input on what might make such an Add On more useful would also be appreciated.
I would say your best bet is to simply make this a login template addon that has a dashboard page with a gallery of beautiful logins that a beginning user can easily select and use, rather than make it a developer addon that only devs can style.
I do NOT like the idea of styling all forms on a site the same way as the login form. The login form is a completely separate UI than the rest of the site, and should only match if it makes sense for that site.
DISCLAIMER: I would never use an addon like this, because I am way too obsessive about style, design, and consistency, and if someone has to purchase a lot of stuff just to get their template to work properly, then I already failed.
I would add to your list that being able to change the width of fields and labels has been useful to me in the past.
The forms I meant are the login, register, change password, and any other system form in addition to the login form. Not the form block itself.
Being able to change widths is one I could add for sure Jordan. Though I am not sure how useful that will be given that the forms I am talking about have pretty much standard widths that won't go changing very much (i.e. password, email, username, etc.).
Thanks for your input.
For sure this will be an Add On catering to end users that are non-technical though it will also be relatively easy for developers like me to make adjustments to it. But the main aim will be non-web developer types.
Having a gallery of forms to chose from for style is an excellent idea! One I had not thought of.
I'll have to think about what you said about not liking all forms on a site to be styled like the login form. I don't know if you looked at the images that me and Mr. NiceGaius uploaded but the standard login form is...well...downright ugly! I would never want web sites styled after that one either :).
Basically all the system forms and a basic contact form will all look the same.
Presently the contact form (as added through blocks or otherwise) and the system forms like login, register, etc. look different. The system forms are super basic and very pre-web 2.0 looking. They look cheap and certainly not like any contact form I have ever put on a web site. Some fields don't even line up correctly. They look like someone slapped them together at the last minute.
My Add On will change all that.
The underlying code at present is somewhat difficult to understand as well. My Add On will change all that in that I will rewrite all such code as if from scratch to be well written, indented properly, liberally commented, using alternative control structure syntax, and with CSS moved out into external files (among other things). That's just in case anyone likes to go mucking about in the code itself but it won't be necessary.
There is no other Add On like this and I think it would be tremendously useful.
Basically install the Add On, go into the interface and click Change and all the files, all the revised code, all the revised HTML, and CSS will be put in the right places (including changes to config.php) to appear in the theme that is in use.
Just like that.
No mucking around in the code or nothing.
Although one will of course be able to change lots of things through the admin interface Add On control panel too if they so desire.
At least that is what I have in mind.
As I rewrite the code do you think it worthwhile to replace code like this...
With it's equivalent of...
That's perhaps a bad example as the original construct seems a bit silly in that the else condition just sets $rcID to itself.
But...my question is whether it would be worthwhile to replace all such shorthand forms of the if block to the longer and clearer form.
To make the code easier to read and follow.
I can see reason to leave such shortcuts in place in that presumably only persons knowledgeable in PHP will view and possibly make changes to the code but even for me...the longer form is easier to read and follow.
BUT on the other hand I understand that if people aren't familiar with how to "read" the ternary operator, then a straightforward "IF" statement is clearer.
Regardless of which method you choose, the most important thing is to be consistent -- obviously you can't go through and change everything in concrete5, but if you are at least consistent with your code it makes it easier for others to understand (otherwise when you see something inconsistent you have to mentally calculate whether it's different for a reason, like it's doing something different than other places, or if the author was just being inconsistent for no reason in particular). Kind of like the "body language" of writing code -- it sends a message on another level besides just what the code does.
Sorry I didn't respond earlier but notice of your response got buried under an avalanche of email until I remembered it.
I am still hoping to get something done Add On wise by the end of this month but I haven't had a chance to do anything with it for nearly a week as I have been so busy with existing client work.
A good thing mind you :).
Anyway...thanks again for your input Jordan.