Silver stripe images are not being displayed on frontend the images are visible only if we login
In dashboard it have to the file permission option i made to form logged user int anyone but still the same issue.
Any help will be appriciated !
Thanks!
It seems that the images need to be published individually of the pages they are in causing headaches. If you add $owns it will cause the images to update/publish when you publish the page itself, the way it should be by default in my opinion.
private static $has_one = [
'TeaserImage'=>Image::Class
//This is my image for the page.
];
private static $owns = [
'TeaserImage'
//Adding this will make sure the image is published with the page.
];
Related
I have a user role called Student and would like to allow them access to Private pages (currently only admin and editor roles can do this). I would like to create a function to do so. I found a post that said to add this to the functions.php in my child theme:
// Allow Students to see Private posts and pages
$subRole = get_role( 'Student' );
$subRole->add_cap( 'read_private_posts' );
$subRole->add_cap( 'read_private_pages' );
But it doesn't seem to do anything. Is there a way to change the ability to access private pages?
Also above it says 'read_private_pages' I want to be sure that they can submit the form on that page as well (not just read the page).
Do you can use plugins? If yes, try the plugin Capability Manager Enhanced.
This plugin is a way to manage WordPress role definitions.
More easy that edit direct in the code.
Please let me first try to explain what I want to accomplish:
I am building a wordpress website for a small, local, but public swimming pool. The pool is only open when the weather is 'fine'. The lifeguard decides in the morning whether the pool will be open or not. This information should be easily maintained and be visible on the website.
I created a widget that displays whether the pool is open or not. The widget recieves the data from a custom table in de wordpress database. The background of the widget will be green when open, red when closed and orange if the lifeguard has not made a decission yet.
So far no problem. For the lifeguard I made an useraccount to login. The only thing he should be able to set/modify, is whether the pool is open today. He should not be allowed to edit/publish pages/posts or see anything else on the dashboard.
So my thoughts are to make the lifeguard a 'subscriber'. But now I am struggling how he can access an settingspage for the 'open or not option'. And where to make this settingspage?
First idea: Make it availaible in backend, but how can I assure it's available for a subcriber?
Second idea: Make it availaible in the frontend. But then, how can I do this?
Has anyone done such a thing? Can anyone point me to a solution for this?
Thanks!
Luc
To make things as clean as possible, I'd register a new custom lifeguard role and an open_pool capability that gets assigned to that role. You would give all your lifeguards the lifeguard role.
You could then add a dialog to either the front or back end using:
if (current_user_can ( 'open_pool' ) {
print $pool_open_close_form;
}
To get you started, take a look at this WPSE thread and the Roles and Capabilities section of the Codex.
Instead of basing this off a subscription, you could base if off a single log in using wp_get_current_user();
For example, in your functions.php file you could place the following.
$current_user = wp_get_current_user();
if($current_user->user_login == 'User1') {
function example_add_dashboard_widgets() {
wp_add_dashboard_widget(
'example_dashboard_widget', // Widget slug.
'Example Dashboard Widget', // Title.
'example_dashboard_widget_function' // Display function.
);
}
add_action( 'wp_dashboard_setup', 'example_add_dashboard_widgets' );
function example_dashboard_widget_function() {
// Display whatever it is you want to show.
echo "Hello World, I'm a great Dashboard Widget";
}
}
This would check the username matches 'User1', then would add a dashboard widget, meaning it would be the first thing the lifeguard sees when they log in. Of course this does mean potentially having a shared log if there are multiple lifeguards.
Sources:
http://codex.wordpress.org/Function_Reference/wp_get_current_user
http://codex.wordpress.org/Dashboard_Widgets_API
You could use a plugin like Adminimize (https://wordpress.org/plugins/adminimize/) to only display the lifeguard some menu function to change the status for the pool and remove all other posts/pages related menu items.
Yesterday I installed a new theme on Wordpress on my self-hosted website. I am aware of the feature that allows you to preview a theme and have used it to select a new Theme that I want to install.
Problem
I do not want to interrupt normal operations of my website, but this new theme requires a lot of customization before it is ready to go. How do I do this?
My Crappy Solution
Is the only way to go about it to run a virtual server on my desktop? This seems tedious, not to mention all the errors I usually get when switching to the "real" server when doing this.
A better way?
I've been searching on SO as well as the WordPress Forum for an answer as to how to do this, but have come up short. I would have thought this is a common question. Maybe I'm using the wrong search terms [themes, customization, before installing]???
Any help is greatly appreciated! Thanks!
Ok, since your question is a pretty good one and probably not a few people are going through the same process when they decide to update their site, I decided to give a try to the get_stylesheet and get_template filter hooks. It turns out that with a very small plugin, you can easily enforce a specific theme(well in this case any logged-in visitor, but you can change this to use any logic you want) according to a specific rule/s.
Here's the code that you need to put in a file in your plugins directory:
<?php
/*
Plugin Name: Switch Theme
Description: Switches the theme for logged-in visitors, while keeping the current theme for everyone else. !!!NOTE!!! Please back-up your database prior using this plugin - I can't guarantee that it will work with any theme, nor that it won't break your site's set-up - USE AT YOUR OWN RISK(I did a quick test and it seemed to be fine, but haven't done extensive testing).
You don't need to switch to the desired theme before that - you want to keep active the theme that you will display to your visitors - the one that you will see will be used programatically.
Before activating the plugin, change the line that says `private $admin_theme = '';` to `private $admin_theme = 'theme-directory-name';` where "theme-directory-name" is obviously the name of the directory in which the desired theme resides in.
*/
class MyThemeSwitcher {
private $admin_theme = '';
function MyThemeSwitcher() {
add_filter( 'stylesheet', array( &$this, 'get_stylesheet' ) );
add_filter( 'template', array( &$this, 'get_template' ) );
}
function get_stylesheet($stylesheet = '') {
if ( is_user_logged_in() && $this->admin_theme ) {
return $this->admin_theme;
}
return $stylesheet;
}
function get_template( $template ) {
if ( is_user_logged_in() && $this->admin_theme ) {
return $this->admin_theme;
}
return $template;
}
}
$theme_switcher = new MyThemeSwitcher();
So - first of all BACKUP YOUR DATABASE! I tested locally with Twenty Eleven being the default theme and a basic framework theme as my custom theme - the theme options and navigation menus were saved properly.
Then all you need to do is to update the file(change the line that says private $admin_theme = ''; to private $admin_theme = 'theme-slug'; where theme-slug is the name of the directory in which the theme you want to use is).
Also - you won't be able to change the Front page and Posts page options, without this affecting the live site, nor will you be able to change the any shared components that both themes use(Site name, Front Page, Posts page, Posts Per Page, etc options, content and so on).
So if you have no clue whether this solution is for you - well, it depends.
If both themes are not relatively complex, then most-likely you should be able to use this hack. If they are though maybe you should do a second installation of your website as others suggested - I think that a second installation in either a sub-domain or a sub-directory would be the best option for you(simply because moving a multisite database is more complex than moving a normal WP database).
I'd setup local apache server with a wordpress installed to customize and test a new theme. When you finished customizing it then you can upload the theme to your live site and activate it. If there are settings that you need to set in the dashboard then you probably will have to adjust them again. That's one way to test/customize a theme before putting it live.
You could create a network (make WordPress multisite with define('WP_ALLOW_MULTISITE', true);, see : http://codex.wordpress.org/Create_A_Network) and then create one sub-site, then turn it "off" with a Maintenance plugin so it is not accessible to users not logged in as admin, export your posts & data from main blog, import them in sub-blog with WordPress default importer, then apply your new theme to this sub-blog and work on it. When everything satisfies you, apply the theme to the main site and deactivate subsite.
I have a Drupal photography website. Images are important to me and no matter how hard I try, how hard I google, I couldn't get those images to work on Facebook Open Graph sharing.
I am using Drupal 7.14.
Users upload photos by using Plupload plugin.
Over-sized photos are automatically resized by Plupload resize function.
These photos are uploaded into a custom-directory. eg. sites/default/files/products/[user:id]/
The photos are thumbnailed and styled according to Drupal core styling. eg. sites/default/files/styles/large/
These photos are displayed in a overriden node page, which I have customized using Panels.
Drupal modules currently don't support Open Graph tags for Panels, so I created them myself using drupal_add_html_head.
// OG Image Tag
$node = node_load(%node:nid);
$user = $node->uid;
$filename = $node->field_product_photos['und'][0]['filename'];
$base_url = "http://www.[my-web-site].com/sites/default/files/styles/large/public/products";
$image_url = $base_url . "/" . $user . "/" . $filename;
// Thus $image_url outputs my full image url address. eg. http://www.[my-web-site].com/sites/default/files/styles/large/public/products/1/[IMAGE].JPG
$element = array (
'#tag' => 'meta',
'#attributes' => array(
'property' => 'og:image',
'content' => $image_url
),
);
require_once 'includes/common.inc';
drupal_add_html_head($element, 'og_image');
I use http://ogp.spypixel.com/Pogo/checker/index.php?url=http%3A%2F%2Fwww.feelsion.com%2Fproduct%2Fd700 to check my OG tags. og:title, og:image, og:url, og:description works like a charm with no problems.
However Facebook Debugger https://developers.facebook.com/tools/debug/og/object?q=http%3A%2F%2Fwww.feelsion.com%2Fproduct%2Fd700 returns only ONE problem. That is - Unable to download og:image: The image referenced by the url of og:image tag could not be downloaded.
I can confirm that ogp.spypixel.com/Pogo/checker/ could display my og:image and the image url is healthy.
I am using HTTP, so HTTPS bug for Facebook og:image is irrelevant.
I have ALT-txt for my images.
I have also included <link rel="image_src" href="[IMAGE_LINK]"into <HEAD>.
My image sizes fulfills Facebook's criteria. At least 200px for both dimensions and not more than 3:1 by proportion.
I have declared og:namespace in my page.tpl.php file.
xmlns:og="http://ogp.me/ns#
No matter how hard I Google and amend the codes and try new images. Facebook still never display my photos and returns the error as in note #9.
Image such as my website logo can be displayed in Facebook sharing. The only images not displaying is from the custom node page/panel.
I have tried to amend FTP permissions for the images but still failed.
I suspect that Plupload plugin is the culprit that the images it resize cannot be rendered by Facebook OG.
I also suspect that could be a case-sensitivity issues on the file name or on the extensions of the image.
I have worked more than 24 hours on this problem and hopes are fading. I am still hopeful that I can find my enlightenment on the problem here. Please do assist me if you know the solution or you are experiencing the same problem.
Thank you.
The problem above occurred because of a HTTP 500 Internal Server Error on the image.
The image appears well with internet browser but is inaccessible by search engine bots.
I have solved the problem by disabling Option FollowSymLinks in the .htaccess file in /public_html/sites/default/files/ folder.
To disable the option permanently, you have to erase the content of the .htaccess file while retaining the file itself in the folder.
Hope that helps, cheers.
I'm in the process of making some improvements to a live Drupal site that's using the Domain Access module to run a number of microsites. I'm trying to find a way of restricting the menus a user can post content to from the node edit screen. A user on one of the domains should only be able to post content to menus associated with that domain.
Is there a simple way of achieving this? I'm guessing there are some hooks I could use, but so far I have been unable to identify them. I'd prefer not to have to install further modules to achieve this and to be able to add some code to the current site to alter the forms. The site is struggling with the large number of modules we've had to install on it already.
According to the readme for the module, you need to set some specific permissions in user management:
To enable this feature, you should grant the 'edit domain nodes' and
(optionally) the 'delete domain nodes' permission to some roles. Then assign
individual users accounts to specific domains to assign them as Domain Editors.
From my experience many moons ago with the module, you can check the global $user object and figure out what domains the user should have access to. You can then use a form alter to remove any options from the select box that you don't want them seeing. As always with Drupal though, it's better to let someone else write the code - so if the Domain module provides this functionality, use it!
Here is some updated code for Drupal 7:
/**
* Implements hook_form_FORM_ID_alter().
*/
function MYMODULE_form_page_node_form_alter(&$form, &$form_state) {
global $_domain;
if (isset($_domain['domain_id'])) { // only display domain's primary links
$menus[domain_conf_variable_get($_domain['domain_id'], 'menu_main_links_source')] = $_domain['sitename'].' Main menu';
}
if (isset($menus)) {
$options = menu_parent_options($menus, $form['#node']->type);
$form['menu']['link']['parent']['#options'] = $options;
}
}
Eventually found a way of fixing this for the particular project I have been working on: in module_form_alter I've added the following:-
global $_domain;
if (isset($_domain['domain_id'])) { // only display domain's primary links
$menus[domain_conf_variable_get($_domain['domain_id']
,'menu_primary_links_source')] = $_domain['sitename'].' Primary links';
}
if ( isset($menus) ) {
$options = menu_parent_options($menus, $form['menu']['#item']);
$form['menu']['parent']['#options'] = $options;
}
This restricts the menu options to just the current domain's primary links menu which is just what we wanted.
Thanks to Fabian who pointed me in the right direction earlier.