README.md for v4.0 refers to wet-boew v3.1
Closed this issue · 29 comments
Just starting to look at wet-boew-php v4.0.
The README.md for wet-boew-php v4.0 still says that it requires the dist for wet-boew 3.1 - should this not be the dist folder from wet-boew 4.0?
Best regards,
Michael
Thanks for pointing that out @michael-milette
The branch is misleading. I was getting things ready for when I finally have access to the core v4.0 WET files to start the development.
The v4.0 branch is actually still version 3.1. The only difference is that it's using the two letter extension for file names instead of the three letter extension. I'm hoping it won't have to be a complete rewrite for the PHP files.
I will however update the README.md file, because I'll most likely forget once we're ready for development. I guess I could start with the plain wet theme for version for and move on to the GCWU-FEGC theme later as it becomes available.
I'm glad to have such ambitious people working with me.
Thanks @upsonp .
When do you think a beta of wet-boew-php v4.0 might be ready for me to give it a whirl? Any kind of estimated timeframe would be helpful as I need to provide scheduling guidance to my client.
Also, will there a variable somewhere in wet-boew-php that I can use to determine whether the theme I am using is WET v3.1 or v4.0?
I would like to make my Moodle theme variant work with both versions of WET but I also may want to optimize how things are displayed at times by taking advantage of v4.0 features with a fallback for those still using v3.1.
@michael-milette I'm off tomorrow so I'll have a look and see if I can get the basic wet theme up and running in the v4.0 branch. Provided my two year old is content with just watching TV or playing with toys. She's pretty independent and doesn't like me touching her stuff, in which case I have lots of time for programming, but occasionally she'll want to go outside or some silly thing, kids today.
I like the version variable idea. I don't see any reason why we can't put that in there to be used in the header file comments. Right now it just says we're using wet, but there's no indication of what version.
Do you have a preference for where it goes?
Maybe a $_SITE['wb__version'] in the main dist-php/config/config.php file?
Thanks @upsonp.
dist-php/config/config.php seems like a good place to put the new variable:
$SITE['wb_version'] = "4.0.0";
Enjoy your "day off" ;-)
Best regards,
Michael
@pjackson28 what should we be using as a base for variants
I'm looking at the wet-boew/wet-boew-dist v4.0-dist branch.
@upsonp I would recommend branching your existing work so it continues to use v3.1 and then building the v4.0 variant in the other branch. Pretty much your v3.1 variant should go into maintenance mode and should be actively developing for v4.0 (like is being done in WET core). For now we have v3.1 in the master branch and v4.0 in the v4.0 branch (will sooon make v4.0 the master and v3.1 will get its own v3.1 brnach).
@pjackson28 Yeah, that's what I'm working on, updating PHP v4.0 from the v3.1 branch, but I need a copy of the wet core files to work from there use to be a dist folder in wet-boew-dist master branch that I get all the include files from (javascript, css, etc...), but there's not dist folder in the v4.0 branch to use. It looks to me like everything is right in the root directory for the wet-boew-dist v4.0-dist branch (assets, css, js, etc...)
So is wet-boew-dist branch v4.0-dist the correct branch I should be using to get the core files for the php variant from?
@upsonp Yes, v4.0-dist is where you can get the latest v4.0 pre-compiled files (for now). It will replace v3.1 in master-dist further down the road (where v3.1 would go to v3.1-dist).
Thanks that's what I needed. I am starting by cleaning out the demos-php and dist-php/config themes. I'm only leaving the theme-wet files and will merge other themes in as they're added.
I'm hoping I'll just have to update the dist-php/inc files, but I don't think it'll be quite that easy.
I should probably quits for tonight while I'm ahead, but...
@pjackson28, are there any plans to restructure v4.0-dist so the assets, js, css stuff will be in a dist folder like it currently is for v3.1
Just curious, it'll be a simple fix for the PHP variant if it changes later.
@upsonp We haven't planned on making any such change. The dist folder is an artifact of when both src and dist were in the same zip file. Now that the source and production files available as separate downloads there really isn't a need for that folder any more.
@pjackson28 How do you plan to handle themes? in version 3.1 there were separate folders for each theme with the specific images like the favicon.ico, in v4.0 the favicon.ico is just in the assets folder.
A couple of reasons to keep the dist folder:
- Backwards compatibility - At CodeFest last year, I was assured that WET 4 could be a dropped-in replacement for WET 3.1 with minimal change
- Clean organization of files - Although you don't distribute both source and dist together, people combine other folders. For example, in my wet-boew folder, I have dist, dist-src, demo, dist-php, and demo-php. In production, I have dist and dist-php. It would become a lot more difficult to manage if they were all mashed together.
Best regards,
Michael
One more... having a dist folder allows me to easily rename the folder when testing newer/older version of WET..
@upsonp Themes are being handled as separate repos in v4.0 (e.g., theme-gcwu-fegc). This is so it is easier to make themes an extension of WET core (also makes the build script simpler now that ll HTML is generated by the build script). You don't need to have separate repos for the PHP variant (since you are just dealing with the markup).
@michael-milette I'm not sure who gave you such an assurance but that is not possible. WET v4.0 is an entirely different framework with the old grid system being replaced by Bootstrap, jQuery Mobile removed, a whole new plugin architecture, everything rewritten, redesigned and refactored for mobile optimization including size and speed. There will be migration effort to bring content from v3.1 to v4.0, although we are trying to minimize that effort where we can. The five sites that have migrated to v4.0 didn't find it too difficult (especially because of the well supported Bootstrap) but it does take some effort.
As for a dist folder, everything within the dist zip file is now generated by the build (including HTML). So effectively the zip file itself is the dist folder. If we were to restore the dist folder then it would be the only thing at the zip file root. If having a dist folder is beneficial then you should unzip the files into a dist folder.
@pjackson28 Thanks, I can see building separate themes in separate branches beneficial. Concerning the dist folder issue. It might be beneficial to have demos separated out, it's not a necessary component of the distribution, but I don't think it'll makes a huge difference in either case.
I'm just about done the first v4.0 example for the index-en.html and index-fr.html pages. There's still going to be a lot of modifications I need to make. I don't need theme specific menus and footers any more so I can cut quite a bit out, but it also means I have a ton of orphaned variables in the config files.
I'll put it in the wiki for upgrading from PHP 3.1 to 4.0, but while I'm thinking of it. I'm keeping the main file names the same so upgrading for PHP will be just download the branch with the PHP Theme for your site and the corresponding WET core theme. Drop them into where you're currently keeping the /dist/ (for the wet core 3.1) and the /dist-php/ (for PHP 3.1) and away you go. At least I hope it'll be that easy...
As far as themes are concerned, I really like having them each in separate folders. One of the features I included in the Moodle variant is to enable administrators to select their WET theme from a theme configuration menu. Not only does this make it flexible, but as a developer it allows me to easily determine if an issue is related to a specific theme or to the wet-boew/wet-boew-php implementation in general. It also enables us to help clients envision what a site might look like on their intranet or internet site for example.
At the risk of creating backwards compatibility issues and contradicting my previous post, it would be nice to see the following show up in the WET-BOEW-PHP implementation:
A. Putting all theme related files in one folder structure to make it easier to zip up the files and distribute a particular theme update.
For example, basic instructions for cloning the ogpl theme to one called custom involves:
- Cloning the dist/theme-ogpl folder to theme-custom
- Cloning the dist-php/config/theme-ogpl folder to theme-custom
- Cloning the dist-php/theme-ogpl folder to theme-custom
- Searching for the string ogpl and replacing it with custom in the .php, *.html, *.js and *.css files contained in each of the above mentioned *theme-custom folders. Use a tool - there are over 700 instances to be replaced across 21 files.
- Editing config/theme-custom/config.php and replacing the site name in the following variables:
$_SITE['ogpl_sig_eng']
$_SITE['ogpl_sig_fra']Why do I clone the OGPL theme instead of the base theme? Because it just seems to work better, is easier to search and replace the string "ogpl" than "base" and already includes a placeholder to put a logo for quick jobs. I've probably missed initializing some base theme specific variables. Speaking of which...
B. Making the variable names in the themes consistent from one theme to another. For example, here is a partial list of variables that provide the same functionality from one theme to the next but have different variable names in each of the themes when they exist:
$_SITE[$gc_theme.'_sig_eng']
$_SITE[$gc_theme.'_sig_fra']
$_SITE[$gc_theme.'_cmblang_text_eng']
$_SITE[$gc_theme.'_cmblang_href_eng']
$_SITE[$gc_theme.'_cmblang_text_fra']
$_SITE[$gc_theme.'_cmblang_href_fra']
$_SITE[$gc_theme.'_langalt_eng']
$_SITE[$gc_theme.'_langalt_fra']
$_SITE[$gc_theme.'_fullhd_text_eng']
$_SITE[$gc_theme.'_fullhd_text_fra']
$_SITE[$gc_theme.'_mobile_hide1_text_eng']
$_SITE[$gc_theme.'_mobile_hide1_text_fra']
$_SITE[$gc_theme.'_mobile_hide2_text_eng']
$_SITE[$gc_theme.'_mobile_hide2_text_fra']
$_SITE[$gc_theme.'_mobile_hide3_text_eng']
$_SITE[$gc_theme.'_mobile_hide3_text_fra']
$_SITE[$gc_theme.'_sft_text_eng']
$_SITE[$gc_theme.'_sft_text_fra']
$_SITE[$gc_theme.'_fullft_text_eng']
$_SITE[$gc_theme.'_fullft_text_fra']
$_SITE[$gc_theme.'_fullft_in_text_eng']
$_SITE[$gc_theme.'_fullft_in_text_fra']...where $gc_theme can be one of:
- base
- gcwu-fegc
- gcwu-intranet
- wet-boew
- ogpl
- custom - if you followed my theme cloning instuctions above.
C. Continue to ensure theme setting variables get initialized using the technique @upsonp has been using in the disp-php/config/config.php file. For example (taken from the existing file):
$_PAGE['issplash'] = (!isset($_PAGE['issplash']) ? 0 : $_PAGE['issplash']);I really like this technique which allows you to override settings or just go with the defaults. In addition to the list mentioned in B. above, here are a few more that could also be initialized in the config file to enable the theme to work out of the box with fewer errors. Wish I had more time to find them all:
$_PAGE['short_title_eng']
$_PAGE['short_title_fra']
$_PAGE['title_eng']
$_PAGE['title_fra']
$_PAGE['sub_title_eng']
$_PAGE['sub_link_eng']
$_PAGE['sub_title_fra']
$_PAGE['sub_link_fra']Hope this helps!
Best regards,
Michael Milette
@michael-milette Thanks, I got a lot of what you were saying in that last post, I think I'll have to digest it and come back to read it a couple times to make sure I understand everything.
I have to get through the v4.0 examples so I know exactly what's going to have to be done.
@nschonni, and @pjackson28 Can either of you tell me what this section of code from the https://github.com/wet-boew/wet-boew-dist/blob/v4.0-dist/demos/theme-wet-boew/index-en.html is for:
<section class="wb-mb-links col-xs-12 visible-sm visible-xs" id="wb-glb-mn">
<h2>Menu</h2>
<ul class="pnl-btn list-inline text-right">
<li><a href="#mb-pnl" title="Menu" aria-controls="mb-pnl" class="overlay-lnk" role="button"><span class="glyphicon glyphicon-th-list"><span class="wb-inv">Menu</span></span></a></li>
<ul>
<div id="mb-pnl"></div>
<section>@upsonp It is the placeholder for the new mobile panel and its triggering button.
@pjackson28 - that was Mario Bonito during his presentation on the last day who said it would be backwards compatible. In fact he said you could just drop in WET 4.0 and your site would continue to work, although it would not see the new feature and would only see minor improvements in performance. Everyone was impressed by this statement.
@upsonp - Your approach works for me f I can continue to drop WET-BOEW into a dist folder and WET-BOEW-PHP into a dist-php folder.
Best regards,
Michael
@michael-milette He stated that as a goal and something he'd investigate but it turned out to be something that was not really achievable and ended up being way more work in the end for implementers and WET developers. It would have effectively meant three different versions of WET to support (v3.1, v3.1/v4.0 hybrid and v4.0) which would have made the two official versions suffer (v3.1 and v4.0). So it was nice in concept but didn't end up being practical or worthwhile for anyone involved.
@michael-milette @pjackson28 @crochefort @nschonni
I've merged my v4.0 branch into the main PHP variant v4.0 branch for testing and critique. I kept quite a bit of code, but it looks like it was a total rewrite because of the restructuring of the directories. Note, in theory this should work with existing v3.1 sites with little change to PHP code, provided the user also acquires the core v4.0-dist files. I've kept the five basic files and their directories as well as the major variables PHP pages should have been using (head-doc.php, head-css.php, head-nav.php, foot-nav.php and foot-end.php).
The major change is I've done away with themes folders. There is still some legacy code that could be removed, server pages don't exist in the samples and a lot of variables set in the config-xx.php files.
More tomorrow if I can find time.
Thanks Patrick... Monday if I have time i'll call you to discuss about the setup. I already have one vhjost ready for v4 on my dev server.
Seeing the basic config that need to be change and i'll be able to see how long it can take to move a site from v3.1 to v4... Like i did for changing the site from 3 letters extenstion to 2 letters!
I've actually realized the big change that will require updates to a website is with the menus. The HTML and AJAX code for the mega menus has been changed which will require a sites menu to be updated. Also it seems the code for the left side (Secondary Navigation) menu itself is different.
@upsonp The markup in v4.0 was rebuilt from scratch to minimize the size and improve performance. A lot of divs were removed (all throughout the structure), classes and ids were moved around and renamed, other markup and classes were added and removed. I would be careful with trying to do just delta changes as you could miss something which could break some v4.0 functionality or leave in extra bloat. If you do keep going with delta changes, you should do a comparison between the WET v4.0 markup and your PHP generated v4.0 markup to make sure they are the same and nothing is added or removed.
With the removal of the themes, how are the different themes going to be supported now?
@michael-milette I don't know about the core distribution, and this might change for the PHP variant depending on how much a PITA it turns out to be, but I plan on developing each theme in a separate branch (v4.0-wet-boew, v4.0-base, v4.0-gcwu-fegc, etc...) You'll be able to download which ever branch you want the theme for, then you just tell your personal site which folder you want to access.
If it turns out to be an issue, I don't think it'll be hard to repackage the themes in one folder with the theme sub directories as it was before. I really can't say until the core WET 4.0 with it's other themes becomes available to me. I'm hoping it'll just be different icons and css classes and the HTML structure will be exactly the same, in which case we won't need separate PHP variants for each theme. The variant will just point to the core distribution folder with the theme you want to use as your sites "skin".
Also as it turns out a bunch of files I thought I had uploaded on Saturday seem to be missing from the PHP v4.0 as well as my personal v4.0 branches. I won't be able to fix it until I get home.
Thanks @upsonp. Let me know when you've uploaded them. Looking forward to trying out what you've got so far.
Have a great day!
Michael