OJS OCS OMP OHS

You are viewing the PKP Support Forum | PKP Home Wiki



Theme development: Segmentation, control and normalization?

OJS development discussion, enhancement requests, third-party patches and plug-ins.

Moderators: jmacgreg, btbell, michael, bdgregg, barbarah, asmecher

Forum rules
Developer Resources:

Documentation: The OJS Technical Reference and the OJS API Reference are both available from the OJS Documentation page.

Git: You can access our public Git Repository here. Comprehensive Git usage instructions are available on the wiki.

Bugzilla: You can access our Bugzilla report tracker here.

Search: You can use our Google Custom Search to search across our main website, the support forum, and Bugzilla.

Questions and discussion are welcome, but if you have a workflow or usability question you should probably post to the OJS Editorial Support and Discussion subforum; if you have a technical support question, try the OJS Technical Support subforum.

Re: Theme development: Segmentation, control and normalizati

Postby juli » Mon Sep 16, 2013 4:20 am

Hi folks!

I'm a OJS deployer and developer, my company have been developed some plugins and themes that we are working to contribute. I'm very happy to see this discussion about the theme system.

I think that the CSS compiler is really good option, we have tested compass with OJS, also phpless seems a really good option. But there is an other point that must be considered. All CSS potency some times can not substitute the HTML structure for some theme implementations. In our experience a template changes are necessary in the most theme implementation with a custom design to no do dirty CSS solutions (that always generate problems with some browsers...).

Are the PKP team planing allow the HTML template rewrite in the theme plugin? I say it because in some installation we have need to change the templates in base directory and this generate a maintenance problems. I encourage you to implement the theme inheritance to allow HTML changes in every theme plugin!

thanks a lot for your work!
juli
 
Posts: 13
Joined: Mon Jul 16, 2012 1:18 am

Re: Theme development: Segmentation, control and normalizati

Postby asmecher » Mon Sep 16, 2013 7:17 am

Hi juli,

For our future plans, I'd suggest having a look at the OJS 3.0 alpha; it includes a complete front-end rewrite and does make use of LessPHP. I'm actually working on theme support at the moment so can answer specific questions about it.

Regards,
Alec Smecher
Public Knowledge Project Team
asmecher
 
Posts: 8425
Joined: Wed Aug 10, 2005 12:56 pm

Re: Theme development: Segmentation, control and normalizati

Postby mbria » Tue Sep 17, 2013 2:44 am

Hi Juli,

Thanks a lot for your comments. I full agree with your thoughts as you can read at:

" In future we will need a template system that allows themes to build variations based on inheritance and functions to get all the control."
"I believe template overwriting (or to be more precise "inheritance") it's an important improvement, a "must be" in future for every OxS product.
I'm not a big fan of smarty but if we are following with it (I full understand a change here means a huge task and in confidence I'm unsure it will mean a real improvement in performance and features) I believe we need to migrate to version 3 to take advantage of the "Template Inheritance" features."

Source: viewtopic.php?f=9&t=9381#p39473

Alec answered this:
I haven't yet assessed Smarty 3.0 but I'm fairly sure it's off the table for the OJS 3.0 release; we simply have too many other things to tackle at the moment. I think the way we're treating templates already in the master branch shows major improvement on the 2.x approach. Like transitioning away from ADODB, I would love to modernize our Smarty implementation, but other things are currently more pressing. Once we have OJS fully modernized as per OMP 1.0, our platform will be much easier to shift in this way -- currently we're basically maintaining two (or more) platforms at once. (We will have to consider how OCS and OHS fit into this, of course, but that's a discussion we're putting off until later.)

Source: viewtopic.php?f=9&t=9381#p39479

So in front of the "we are overwhelmed right now" I didn't find the right replica. :-)

Sorry if I extend this but I need to be sure we are in the same page here:

HTML is the structure of the building, while CSS is the painting and the furnitures.
If you want to shift floor 1 with floor 7 I won't be able to do it with CSS i need to change the structure.

If we want to (and this is a brief list):
  • Create a different page layout...
  • Move the footer as a sidebar...
  • Create a plugin that injects HTML code in content area...
  • Modify the login block to be shown as header element...
  • ...

In all the former cases, the clean solution (or the only solution) is to modify OJS' templates.

I full understand PKP's priorities and I don't have the competence and the responsability to discuss them.

Any case, my conclusion is that CSS won't be enough for real theming (although yes, the HTML in OJS 3.0 is much more better than former versions) so it's something that we will need to face sooner or later.

So Alec, then only proposal I can make here is: It's ok for you (and pkp) if somebody tries to develop this?

I other words: if Juli, myself or whomever finds time to review OJS 3.x and include smarty 3 -with inheritance- or much more hooks (let us know if you are thinking in a better approaches) will PKP review the code to be taken in consideration for next version?

I mean: Do you want help on this?

Cheers,
m.
mbria
 
Posts: 292
Joined: Wed Dec 14, 2005 4:15 am

Re: Theme development: Segmentation, control and normalizati

Postby asmecher » Tue Sep 17, 2013 9:55 am

Hi Marc,

Absolutely, that kind of help would be welcome. It's entirely possible that Smarty 3.0 will be a drop-in replacement for the current version we're using -- i.e. it's backward compatible but offers a bunch of new features -- in which case it would be easy to gradually add new designs (e.g. making use of inheritance). In any case, I'm currently working on theme support (CSS at least) and would welcome some input on these subjects.

Thanks,
Alec Smecher
Public Knowledge Project Team
asmecher
 
Posts: 8425
Joined: Wed Aug 10, 2005 12:56 pm

Re: Theme development: Segmentation, control and normalizati

Postby juli » Wed Sep 18, 2013 5:31 am

mbria wrote:HTML is the structure of the building, while CSS is the painting and the furnitures.
If you want to shift floor 1 with floor 7 I won't be able to do it with CSS i need to change the structure.

If we want to (and this is a brief list):
  • Create a different page layout...
  • Move the footer as a sidebar...
  • Create a plugin that injects HTML code in content area...
  • Modify the login block to be shown as header element...
  • ...


exacly, that's the main point; where CSS is not enought.
juli
 
Posts: 13
Joined: Mon Jul 16, 2012 1:18 am

Re: Theme development: Segmentation, control and normalizati

Postby mbria » Thu Sep 19, 2013 12:56 am

Ok, so let's say the the call is something like:

"Looking for developers to migrate OJS from smarty 2 to smarty 3 to extend it's template system with inheritance."


Juli, do you like/could participate in this?
Alec, do you know if there is somebody else that want to join?

Alec, do you want us to create our own git repo or do you prefer to create a branch in the official PKP one?

BTW, I don't know Juli, but I will do this in my spare time so I can't promise deadlines.

Cheers,
m.
mbria
 
Posts: 292
Joined: Wed Dec 14, 2005 4:15 am

Re: Theme development: Segmentation, control and normalizati

Postby asmecher » Fri Sep 20, 2013 4:44 pm

Hi all,

With respect to Smarty 3, I'd suggest starting with your own fork; that way you'll both be able to collaborate without us centralizing the effort by gatekeeping commits. Pull requests to us would allow us to easily review proposed changes. The master branch should be usable for development if not entirely stable.

FYI, I've just pushed up some basic work around themes to the master branch. Here's how it looks...
  • All stylesheets are now included via TemplateManager::addStyleSheet(). These are sent to the browser via the header template.
  • Compiled CSS delivery is now done via a component. The main CSS is added to the headers in the PKPTemplateManager, and served up by PageHandler (which, incidentally, also serves up the top navigation and sidebar components). Plugins can manage compiled CSS via the same component, as implemented in the ThemePlugin base class.
  • Themes are implemented like this. If the theme isn't going to use LessPHP, then simply using TemplateManager::addStyleSheet will work.
  • Order of stylesheet inclusion can be roughly controlled by adding a second optional argument to PKPTemplateManager::addStyleSheet to define the sequence, i.e. STYLE_SEQUENCE_CORE, STYLE_SEQUENCE_NORMAL, or STYLE_SEQUENCE_LAST. Plugins can of course intervene in the set of added stylesheets before the header template outputs it to the browser.
  • As in OJS 2.x, both the journal and the site settings allow for the selection of a theme plugin. Unlike in OJS 2.x, the "default" theme is configured upon installation and selecting another theme results in the default theme's CSS no longer being included. (No more overlaying overrides to remove default styling before adding your own.)
There are several practical concerns that led to this design:
  • We can't necessarily serve files (e.g. cached compiled CSS) directly from the cache/ subdirectory; admins may (reasonably) block the contents of that directory from direct access.
  • It's not ideal to compile everything into a single CSS cache -- if e.g. an installation has several journals, then each would have to have a totally different (and mostly duplicated) CSS cache. Browsers going from one journal to another would see unnecessary overhead. Therefore "core" CSS is compiled and cached separately from "theme" CSS, though that's not to say that plugins can't monkey with core CSS compilation too.
  • Not all CSS can be delivered compiled -- there's a limited amount of third-party CSS that doesn't respond well to LessPHP compilation. This is managed as uncompiled CSS, served separately, and kept minimal.
I still have several things to work on:
  • Impact on caching, i.e. how often are the stylesheets requested by browsers?
  • The separation of "core" and "default theme" styles needs to be reviewed; it's currently a mess.
  • Some practical cases for theme plugins intervening in built-in stylesheet inclusion and compilation need to be checked; it might be desirable to inject hooks into the LessPHP compiler as much of the core styling is built on one .less stylesheet including another.
All of this is currently committed in the master branch of OJS (and OMP), so if you'd like to try it out or comment on the code viewable via http://github.com/pkp/ojs, thoughts are welcome.

Regards,
Alec Smecher
Public Knowledge Project Team
asmecher
 
Posts: 8425
Joined: Wed Aug 10, 2005 12:56 pm

Re: Theme development: Segmentation, control and normalizati

Postby mbria » Wed Sep 25, 2013 2:57 am

Impressive post Alec.

Thanks a lot for the info and the indications.
So now, the ball is in our court.

I'm trying to contact the few OJS theme developers to see if they are also interested in joining. Juli, what about you?

As soon as we know how many resources do we have, the idea is creating a mailing list to keep the contact and split the work.

Cheers,
m.
mbria
 
Posts: 292
Joined: Wed Dec 14, 2005 4:15 am

Re: Theme development: Segmentation, control and normalizati

Postby rootl » Tue Oct 01, 2013 6:22 am

Thank you for the updates, Alec.

I created a theme for one of our OJS journals. I tried to avoid affecting core code as much as possible. Certain things we needed required template changes, such as Login/Register links in the header instead of the menu. Of course these changes affect all journals on our OJS instance.

I have a style switcher script that I am working on using regex to conditionally display styles for the user area of the Journal Manager, dependent on what Journal the user is viewing or managing.

I would like to contribute to a 'template switcher' script.
Or perhaps if we incorporate a Bootstrappish approach like mentioned earlier in this thread, we then would not need to alter core files.

In any case, please add me to the mailing list. I would like to contribute and test out modifications for both OJS and OMP.
rootl
 
Posts: 59
Joined: Wed Feb 20, 2013 7:17 am

Re: Theme development: Segmentation, control and normalizati

Postby ianthe » Tue Apr 22, 2014 3:13 am

Hi :)

Here at the University of Edinburgh, we host 9 journals through OJS 2.4.2 (http://www.journals.ed.ac.uk) with more on our test server about to be released to live. With the increasing popularity of the service, a new design has been created for the main page and I've been busy working on getting it into CSS and applied.

I haven't been able to put the CSS into sitestyle.css as this impacts all the journals. For example, the new design has a background image and if I apply this in sitestyle.css to body, every journal (unless it has it's own background image), then gets the new background which is not what we want. The replies in this post have been really helpful - sitestyle.css is for site wide styles.

So how about if I just want a styling for the main page and for this not to be cascaded down into all the journals?

I've made a separate stylesheet and in /classes/templates/TemplateManager.inc.php, if a journal isn't loaded (so we're on the main page), I then add the stylesheet.

This works fine, but obviously since I've changed a core file, each time we upgrade I'm going to have this code back in. Is there a better way to do this?

If not, would it be useful for me to add this into the code base by creating a separate upload box on Home > User > Site Administration > Site Settings for a main page stylesheet (underneath the site stylesheet)?

Thanks in advance,

Ianthe Sutherland,
University of Edinburgh.
ianthe
 
Posts: 2
Joined: Tue Apr 22, 2014 2:34 am

Re: Theme development: Segmentation, control and normalizati

Postby asmecher » Thu Apr 24, 2014 4:44 pm

Hi Ianthe,

Note that the thread above is for the not-yet-released OJS 3.0; you're working with OJS 2.4.x.

I haven't heard of a requirement for index-only theming, so I'm hesitant to add support for a stylesheet upload for just that page.

The next release (OJS 2.4.4, due within a few weeks) will have an additional CSS class applied to the <body> element, which will help permit more specific modifications based on what page is being displayed.

In the meantime, your modification is the most expedient approach. We tend to work with modified installations, and we use both git and diff/patch tools to ensure that we're tracking modifications during upgrade. Alternately, it's possible to write a fairly brief plugin that would accomplish the same modification without requiring alterations to the core code. I could describe in a little more detail if you're interested.

Regards,
Alec Smecher
Public Knowledge Project Team
asmecher
 
Posts: 8425
Joined: Wed Aug 10, 2005 12:56 pm

Re: Theme development: Segmentation, control and normalizati

Postby ianthe » Tue May 13, 2014 5:06 am

Thanks so much for the reply Alec. Sorry that I posted to an OJS 3.0 thread!
ianthe
 
Posts: 2
Joined: Tue Apr 22, 2014 2:34 am

Previous

Return to OJS Development

Who is online

Users browsing this forum: No registered users and 3 guests