Tag Archives: bootstrap

Refacing the cabinets and hardware

Dust every freaking where! There were some new junction boxes and updated wiring but the rest of the room still needed a bit more refacing . The categories.php file proved worthy of a new look, and new look it did indeed receive. I didn’t bruise too much, but the keyboard is a bit tore up now.

In following along with the configuration file layout, I applied the same look to the main categories and product data tables. There were several more actions to hook in than the configuration file, and things got a bit trickier. I couldn’t just place all the cases inside one switch below the data table because the table is actually split into 2 parts, 1 for categories and 1 for products. In theory – yeah right – I thought I could just have the new table rows that now replace the table_block and box coded below the end of the data table – but no go. It would work for the selected action and correct category or product, but would open in a new row underneath EVERYTHING, not the selected row.

To overcome this unwanted behavior I broke the various cases into 3 parts. There are a couple of loops – one around the categories section, and one around the products section. The category actions were moved to the end of the categories data table before the closing loop, and the same went for the products actions. BAM! Everything works as expected. But that is only 2, what about the 3rd I mentioned? The 3rd was a single action for creating a new category. I placed this at the end of everything and made it open up in a modal window. Perfect! A few knobs in the name of icon buttons and the exterior is done.

Moving on to the interior now – the old product administration sure has been the same from day-to-day, week-to-week, year-to-year, decade-to- WHAT! It really has been over a decade. Outstanding longevity!

So inside the product editing area I consolidated all the language fields into a Bootstrap nav-tab. I knew it would work as I’ve done it before with Bootstrap V2 series. For every installed language, the tab displays its corresponding flag icon. Within the tabs content are the name, description, and more fields. This looks nice and tidy giving lots more room for storage.

The image area falls immediately below the tabbed content inside of a Bootstrap well allowing room for any additional images. This part could probably be revisited as I am still making use of jQuery UI elements to control the additional images features. – which brings us to the date picker.

To the right of everything there are 3 sets of BootStrap list-groups. Everything basically falls in order as the old layout did, status radios, date picker, and manufacturer drop down.  The date picker is still fueled by jQuery UI – there is a Bootstrap date picker available, and it is in use on the catalog side of the community build – but I don’t know enough about it to know if it is a suitable admin replacement due to the superb localization features that the jQuery UI date picker possesses.

Under that is a list group that has a nice coat of info blue paint. This keeps the tradition alive for quickly spotting your tax and pricing information. Your not gonna make a dime if you don’t use this area. Even if you leave everything else blank, at least you can coax someone into buying the blank space if the price is right.

The final element of the page, besides a couple of buttons,  is another list group for holding the products weight, quantity and model number. I really wanted to move this into the first list group as they do go together, but doing so would have pushed the pricing info to far down the page. Perhaps the pricing info can go up top and then I can combine them – it’s up to the community feedback.

Our final area is the product preview. This was pretty straight forward – I again made use of the Bootstrap nav-tabs.  For each language all info is loaded in its corresponding tab content. For me there’s not a lot of use for the product preview,  but it is handy for information at a glance, especially if clicking on a product in the sales report.

The newly finished file can be found in the change log here: admin/categories.php

A little more space in the foyer

When visiting the dashboard, things didn’t look too bad, but all those modules did not match anymore, and resizing for responsiveness just wasn’t happening. All that really needed to happen was a small tear down of the table cells, and a replacement of col-md-6 grids. I simple wrapper with id of #dashboard around everything for any other fine tuning and the page was ready to go.

The dashboard modules were now in need themselves though. It was all easy enough, just convert the tables to use bootstrap table and col-md-* classes and the current project page was finished. It was mostly repetitive search and replace work. As I had already changed the tep_image function to use Bootstraps responsive image class, I did have to set that class to false on the smaller icons that are found in the latest news and latest addons modules. Otherwise they all stacked 1 upon the other.

The reviews dashboard module received a little bit different treatment than the others. I did mark up every module to use a glyphicon when and where it could, and the review stars were no exception. Taking the newer review stars function from the catalog side of the osC to Bootstrap build and presto, an instant fit! I did notice however that the whole module had some overflow on mobile devices. So for this one module I added the Bootstrap table-responsive class. Seems to work out well. Just a simple finger swipe to view from one side to the other.

Thus far there have not been any customer sign ups, let alone orders, so I have not fully tested the customers and orders dashboard module, but I have a suspicious feeling they will need the same table-responsive class.

The flot charts needed a col-md-6 class added to them and that was it, but they sometimes like to tilt and sway on resize. Not enough to worry about though.

Overall a nice polished finish. A little wax and you can slide from one end to the other.

I am posting the changes to admin/index.php, but am not going to post each dashboard module,  You’ll have to find them on GitHub.

 

 

Hooking up some safety features

Before the job goes on to much longer its time to set up some safeguards. I don’t care if someone looses a limb or two, but lets not burn the house down. Remodeling the admin involves a lot of testing along the way, and I would like to know at a glance if I am performing something that in reality could be a shop owner about to erase data.

I went ahead and did some slight modification to the messagStack class to make it compatible with Bootstrap Alerts. However, I wasn’t quite satisfied the average alert they rolled out, but rather had my eye on the alerts and notices they have so nicely presented in their own documentation. A quick search of the web found some at bootsnipp.

A had to create a new file to go along with the messageStack, alert_box, but I actually created it some time ago, and just grabbed it off the front end and installed it in the admin. I requirement in application_top.php and its ready.

To view the new classes, check the change-log for admin/includes/classes/message_stack.php, and the new file admin/includes/classes/alertbox.php.

Walls in the way

So now that the preliminary framework is out of the way, its time to knock out some walls, maybe put in a new window, and fix some plumbing leaks. Where to start, where to start!

Well I started with the admin/configuration.php file. This file would become the groundwork for all other files to follow. There are many, many, tables inside the osCommerce admin; and rightly so! A great amount of the data found in the admin is just that – DATA – what goes with data? TABLES – what now? TABULAR DATA.

So whatever is done inside the configuration file will surely follow throughout most of this admin build. I see no reason in tearing down a complete table that holds needed data, but there are extensions of that table that must go. A table inside a table, inside yet another table is not acceptable here.

So down to basics; if it was not the main table holding content, it was torn down and replaced with friendly div elements marked up with Bootstrap classes. I started the page with Bootstraps page header, and from there went right into a panel. Now my cursor is at the main table that will hold our tabular data. So it needs a bit of rebuilding.

First I applied Bootstraps table classes, then added the missing markup – thead, th, tbody. Somewhere along the way there is a <tr> element that renders 1 of 2 depending what row you have selected. Inside that element is some javascript that gives commands for onClick, onHover, etc; etc; Most that I was able to remove with the exception of the onClick directives, and then simply added a class of “active” for the selected row. The Bootstrap table classes already take care of the onHover effects so they were completely removed.

Since the Bootstrap table classes are being used, I also had no other need for the preexisting dataTable* classes that were everywhere. For the heading rows I made a custom class, heading-row,  and changed all the td’s to th’s. For the content rows,  I just removed all the classes. Now I had a nice clean table with Bootstrap hover and stripe effects. Combined with an active class for the selected row, I’d say it looks pretty good.

Now a bit more markup – I wanted this table to be consistent all around. So for each th or td, I calculated what it would take for optimal cell width, and added the col-md-* class, if the cell previously had an align directive, I added a text-* class that corresponded to that align.

Update: 08/12/2014 - I have removed the col-md-* classes as when I was working on the categories.php file I discovered that no matter how I marked it up, col-md-*, col-sm-*, or col-xs-*, it seems best for responsive view to let the table choose its own width.

Now a quick view showed a nice display of data, very consistent across the board.  A click to a row and the active class kicks in highlighting what I want to work with.. but .. wait —

Shit Fire! What just happened? I clicked the row and this Box function reared its head! Now there’s another table sticking out like a sore thumb. Hmm, that table_block, it used to look good, before I started bootstrapping this thing. Now what to do with that data, and how do I present that data without running a full blown query of everything on the page?

Easy enough, borrowing the same check to see what row is selected, I simply added the question of if an action is set. Now inside of this I added the switch and case code, and rewrote it a bit to do away with the $heading and $content arrays and just simply pull the content. Along the way I added various Bootstrap markup to make everything  intuitive and visually appealing.

Now this brought forth another task – where to place the action buttons that are generally found inside the table_block box output.   As it was, you clicked a row, or the arrow icon at end of the row to open up the table box where you were then presented with additional info and any action buttons.   I had wrote a new function for outputting Bootstrap Glyphicons, now I had an idea to use some glyphicons to make action buttons to click on.

At first I used the newer Bootstrap button, tep_draw_bs_button(), to create a button with the icon only, but found it did not quite work as I wanted. Since there was no text to display, I had no way of chaining a title to the button, and I had to use preg_replace to get rid of the space I intentionally left at end of the Bootstrap icon output. So I wrote a new function that would output a small button with a glyphicon in the middle and display a title text on hover. At first I set up the function to use popovers too – but that was just too much and did not always render the same – looked like some sloppy paint on the job – so I quickly removed that aspect of the function.

Now that my glyphicon button was ready, I created one for each action available and placed them in the last cell of the row where one would have previously found the info or pointer icon. As a finishing touch I set up a new row to open when clicking the buttons, the row opens directly under and displays all content.

I could have wrote a new class that mimicked the table_block and box classes, and things probably would have been a little simpler, but there was the question of where to present the data – I really favored placing it in a new row directly under the selected row for a better user experience across devices. That and removing the need to have that new column appear on the right greatly enhances the room the main table has. We shall see just how well this works out when it comes to the module file!

So a few more arrangement’s here and there and the configuration file is done! Now I have a blueprint to use for the rest of the admin. As you now know, I am not interested in getting rid of any tables where tabular data is to be utilized. In all testing – thanks to some good folks at the osCommerce forums, the page appears to render just fine across a wide array of devices.

 

 

 

 

Starting out, Tear it down & Rebuild

So the first thing involved in creating this spiffy new theme is demolition! Forget about the sledgehammer and wrecking ball, the delete key works just as well.

These files pretty much had to be torn down and completely rebuilt:

It just had to happen, no way around it, those files are going to be used to create our new framework in which to house the rest of the admin in. Just like any structure, you need a solid pad to build upon.

I opted to build out an off canvas framework, similar to what is found in the Bootstrap examples . The reason I picked this is to have the ability to hide the left column on smaller devices, yet display the full menu on full sized screens.

So to continue with the new build Boot Strap needed to be added and was placed in the front end (as it is in the community Boot Strap build already):

  • catalog/ext/bootstrap/

Next I added a new stylesheet to the admin – this is where I placed the css markup for the off-canvas framework as well as a few changes to make the theme unique, and not “just another” Boot Strap site:

  • admin/ext/stylsheet.css

Now with that out of the way, there are 2 more files that need slight modification to make use of Bootstraps features:

I basically borrowed the functions already written for the catalog side of the Bootstrap build for form inputs, buttons and select areas. In addition I wrote a new function for outputting glyphicons and glyphicon only buttons. In the general file I added Bootstrap radio input markup for use with tep_cfg_select_option output.  While I was at it a decided to use a nifty script I used in a previous project for theming select inputs to look like Bootstrap buttons.

  • catalog/ext/bootstrap_select/

I did leave jQuery UI in place, but created a slimmed down theme to match the theme I created. The reason being is that there are a few places in the admin that make use of the datepicker, and you just cant beat the language internalization that is part of that. Another reason being is the multiple image functions found within the products edit page seem to depend on some of the UI features.

So with all the above done, I came up with a nice framework to wrap around the admin pages. Now the real work begins, totally remodeling each page so that it blends in with the framework and performs as well on a tablet as a desktop/laptop. I would mention phone too, but don’t expect for one to really use a phone to admin an ecommerce site other than the occasional checking in.