Theming view, block id - drupal

I've created a block in a view, but in de source code that block has the folowing id:
block-views-Work-block_1
'Work', is the name of the view but i identifies the block by 'block_1', isn't there a way to change this to the name of the block for example?
When i see block_1 in my css file it isn't really clear what it is.

In Views 3, you can change that under Basic Settings -> Machine Name.
It doesn't appear to be possible to change the machine name in Views 2.

as keva says, Views 3 has the Ability to change display ids. if this feature is really important to you, go ahead and install Views 3. note that the latest release version is alpha quality. you might try the 6.x-3.x-dev version, which should have more bugs fixed (but possibly also new ones introduced).

Related

Create dynamic stylesheet

I need to allow the webmaster of a plone site to change the "main color" of the site (repercuted on the docuemntFirstHeading, portletHeader, etc).
I think I can use the base_properties.prop file liked to a mystylesheet.css.dtml file.
Is there a way to modifiy programmaticaly the base_properties file (which would repercute the changes in mystylesheet.css.dtml with a "&dtml-maincolor" declaration) ?
I'm using Plone 4.3.3
There was a product for Plone 3 called CSSManager which provided a form to edit the base_properties. It may need some updating of imports to work in Plone 4; Plone 4's default "sunburst" theme does not use base_properties, so there probably hasn't been much motivation for that basic maintenance to happen.
Maybe you can look at its code to find out how to edit base_properties.
https://pypi.python.org/pypi/Products.CSSManager
You can have a look at the stylesheet in adi.slickstyle (disclaimer: one of my humble packages), which collects and unifies all selectors setting col, bg-col and borders, so they can be set at once.
If you want to give a user access to a customizable stylesheet via a Plonesite's UI (=not ZMI), check out adi.ttw_styles (disclaimer: yet another one of my humble packages) it allows to use a 'page'-contenttype as the stylesource, thus you can grant edit-permission to any user you want, easily via the sharing-tab of the page.
The future: Plone 5 is said to introduce LESS based styles, to address this and make base_properties obsolete.

How to make a custom layout in a subtheme from omega 4 Drupal show in appearance settings?

I've started working with the omega 4 theme in drupal, switching from omega 3. I've created a subtheme succesfully, and according to the documentation I want to make my own layout. I've copied over the "Simple" layout from omega to my subtheme folder, as well as the required css and sass files. I've renamed all instances of Simple to Grid (my layout name).
That all seems fine, but when I go into my drupal installation, appearance -> settings -> layouts I still only see the four main omega layouts (simple, divine, hero, off canvas). It claims to show any layout from omega or installed subthemes. Why won't my layout show up for selection?
Additionally: Is it possible to use a different layout for the front page than the rest of the site?
I had the same problem myself and it turned out that in MY.layout.inc I forgot to changhe the value
template = simple-layout
with
template = MY-layout
pamatt: BONUS! I was having the same problem. This fixes it.
A little more detail:
If you follow the directions here it's possible you might miss this explicit reference. I'm updating that page now.
Go to your
themename/layouts/layoutname/layoutname.layout.inc
file (of course, substitute "themename" and "layoutname" with the appropriate names) and look for a line that starts with "template" i.e.,
template = simple-layout
change "simple-layout" to your whatever you named your tpl file, minus the ".tpl.php" part.
I'm coming back to this question since after a long absense of coding I came back to it this weekend and had the exact same problem! Above answers are correct.
Another issue I had was that I had to clear the cache from Drupal -> Configuration -> Performance and not just my browser cache. After clearing the cache it showed up.

Folder Does Not Support Ordering

I see a message This type of folder does not support ordering when viewing the News or Events folder. My understanding is that items contained in such folder, their position order can not be set arbitrarily. Only alphabetical order for their IDs is applied.
From ZMI, I see News and Events folders are of ATFolder type, everything seems the same with the regular folder I just create. What makes such difference? And what is the rationale behind this?
Edit: My bad that Info message in the above image is enabled by wildcard.foldercontents, which I thought due to Plone 4.3.2. However, the issue remains that position order can not be set arbitrarily. The following image attached to illustrate this.
PS: I ever delete the News folder, create a regular folder named news, this way I can set item position order arbitrarily. However, I find the Calendar Portlet within that folder is not working right. The issue happens when I click to switch months. The URL link will be out of its context, I mean, not staying in the news folder. Maybe this is not related to the folder ordering behavior, anyway, just for your reference.
For some reason Plone is shipping with the news and events folders being unorderable.
>>> news = site.news
>>> news.getOrdering()
<plone.folder.unordered.UnorderedOrdering object at 0x112e434d0>
I consider this a bug in plone's initial site installation.
Plone core actually explicitly sets the folder to unordered: https://github.com/plone/Products.CMFPlone/blob/4.3.x/Products/CMFPlone/setuphandlers.py#L250
I don't understand why. I'll change it if there aren't any objections...

Changing skin layer based on URL

I am creating a site which will have a "desktop" and a "mobile" theme. I've two theme packages for this site: mysite.theme and mysite.mobile_theme. The mobile_theme is a stripped down version of the desktop theme, with new views and a reduced set of viewlets. I want to switch between these two themes based on the URL the site is visited from (i.e., mobile.mysite.com vs. www.mysite.com).
As the mobile and desktop themes will share a lot of code, mysite.mobile_theme descends from mysite.theme in the following ways:
1) mobile_theme GS skins.xml has a skin path based on the old theme, so the desktop theme's CSS etc. is used:
<skin-path name="mysite.mobile_theme" based-on="mysite.theme">
2) IThemeSpecific marker subclasses the original one, so views which I'm not overriding for the mobile site fallback to the ones in mysite.theme:
from mysite.theme.browser.interfaces import IThemeSpecific as IBaseTheme
class IThemeSpecific(IBaseTheme):
"""Marker interface that defines a Zope 3 browser layer.
"""
3) I have registered various views in mysite.mobile_theme to override the certain ones in mysite.theme.
4) I've used generic setup to have different viewlet registrations for each theme.
At this stage, if I select mysite.mobile_theme in the "Default skin" option portal skins->properties, everything works correctly: my views are used and the viewlets settings from the mobile_theme's GS profile are picked up correctly. So it appears the theme is set up correctly overall.
As mentioned above, however, I would like to swap between these two themes based on URL.
First, I swapped the "Default skin" back to "mysite.theme". I then created an access_rule in the root on my Plone site, roughly following these instructions to select a skin based on URL. It's at plonesite/access_rule and is set up as the access_rule for the plone site:
url = context.REQUEST.get('ACTUAL_URL', '')
if 'mobile' in url:
context.changeSkin('mysite.mobile_theme', context.REQUEST)
else:
context.changeSkin('mysite.theme', context.REQUEST)
I've also tried using context.REQUEST.set('plone_skin', 'mysite.theme') rather than calling context.changeSkin(...).
Using this setup, the viewlets displayed change correctly based on the URL I've used--so it looks like the skin is being changed at some point--but the mysite.mobile_theme's view classes/templates are not being used in preference to mysite.theme's. In summary:
If I call from a URL containing "mobile" I get mysite.theme's views, but mysite.mobile_theme's viewlet registrations.
Otherwise, I get mysite.theme's views and mysite.theme's viewlet registrations.
It looks like I might have to hook into the traversal mechanism to change it so if "mobile" is in the URL, the mysite.mobile_theme's views registered against its IThemeSpecific are chosen rather than the mysite.theme ones, but I'm not sure this is correct nor how I'd go about this.
Can anyone give me some pointers?
UPDATE 3hrs after originally asking
To answer my own question (which I can't do for another 5 hours due to SO's rules):
"""
It would appear that you must patch much lower down in the stack to make this work. I looked at how it was done in plone.gomobile, and they monkeypatch the skin choosing code itself. See:
http://code.google.com/p/plonegomobile/source/browse/gomobile.mobile/trunk/gomobile/mobile/monkeypatch.py
"""
You could use collective.editskinswitcher. Its main use case is to use the Plone Default theme on say edit.example.com and My Custom Theme on www.example.com. You can probably tweak its property sheet to fit your use case though.
Since the 'mobile theme' use case is fairly common I would accept patches to make that easier; or I may work on that myself some time.
(BTW, note that there is a fix-browser-layers branch that may help when you miss some items that are registered for a specific browser layer; seems ready to merge except that I would like to add some tests first.)
I have done this in some prototypes of mobile themes. Please consider thoses two addons not ready for production:
https://github.com/toutpt/plonetheme.jquerymobile
https://github.com/toutpt/plonetheme.senchatouch
The related code is:
The patch on browserlayer to mark the request with my theme layer: https://github.com/toutpt/plonetheme.jquerymobile/blob/master/plonetheme/jquerymobile/layer.py
The patch on plonetool to add ##mobile on every content page: https://github.com/toutpt/plonetheme.jquerymobile/blob/master/plonetheme/jquerymobile/PloneTool.py
The patch on skintool to tell skin layer is this one if browser layer: https://github.com/toutpt/plonetheme.jquerymobile/blob/master/plonetheme/jquerymobile/SkinsTool.py
If you are using plone.app.theming, you also can switch your diazo theme: https://github.com/toutpt/plonetheme.jquerymobile/blob/master/plonetheme/jquerymobile/transform.py
Do I understand correctly that at the mobile URL your skins are correct, but your Zope3 Views are not? Which makes sense to me, since the view classes are based on Interfaces. In the same code above, where you use context.changeSkin, add:
from zope.interface import alsoProvides
alsoProvides(context, IMobileView)
and have your view zcml specify for ... IMobileView
[edit: on second thoughts, this really should be what happens when you change the skin - where the additional inteface will be your "IThemeSpecific" - so I'm not sure what's at play here, but it wouldn't hurt to try alsoProvides(context, IThemeSpecific)]

Menu path in Pathauto

How do I get pathauto under Drupal 7 to generate a URL alias by the full menu path?
Just an update in case anyone comes across this with a more recent version of Pathauto/Token. This worked for me:
[node:menu-link:parents:join-path]/[node:menu-link]
I ended up using:
[node:menu-link:parent:url:path]/[node:menu-link]
Heavy caution though: If the node does not have a menu link, you'll end up without an automatically aliased page. On the bright side, this might make you aware of orphan pages. (Consider it a feature!)
Note that using the pattern:
[node:menu-link:url:path]/[node:menu-link]
will only give the node's menu link, not that of the parent (which would be needed to reference the parent's path).
Or the pattern:
[node:parent:url:path]/[node:menu-link]
throws an error in my instance of Drupal 7 about invalid tokens (even though I have the token module installed).
[node:menu-link:parent:url:path]/[node:title]
If the node is not in the menu, then it does not create an alias. Otherwise this seems to work for n-tier menus.
I think it has to be this pattern now:
[node:menu-link:url:path]/[node:menu-link]
"path" instead of "alias"
You'll need to install the contrib Token module as well -- although a lot of the features of Token are part of core in D7, some of the edge case tokens (like the full menu path of a given node) aren't provided by core automatically.
With that installed, I believe that [node:menu-link:parent] or [node:menu-link:parent:url] should work.
The pattern that works for me is the following:
[node:menu-link:parent:url:alias]/[node:menu-link]
I also intalled the Token module like Eaten suggested. Don't know if [node:menu-link:parent:url:alias] is part of core or lives in contrib.
If you're attempting to make aliases for pages that are 3rd level or deeper, for example:
Home page
> Level 1 page
> Level 2 page
> Level 3 page
and you want the alias for Level 3 page to look like http://domain.com/level-1/level-2/level-3, I got it to work for me by setting my pattern to:
[node:menu-link:parent:parent:parent:title]/[node:menu-link:parent:parent:title]/[node:menu-link:parent:title]/[node:title]
Notice that I added :parent to the token, and for the first one I added it twice.
Enjoy!
[node:menu-link:parents:join-path]/[node:title].html
This is the solution I use:
[node:menu-link:parents:join:/]/[node:menu-link]
It will separate parent menu items with a dash. That is what I need.
For anyone who stumbles upon this answer, and wonders how to add this:
Configuration > Search and Metadata > URL aliases, then create under "Patterns" tab.

Resources