I am building a wordpress plugin with the boilerplate framework (https://wppb.me/). That all works fine. I have an annoying issues which I cannot solve.
the boilerplate makes per object one php file. In this php file all funtionality for the object is arranged. Pages, lists, validations etc.
Example in the file for contact there is a method contactlog_menu:
Object: contact
public function contactlog_menu()
{
add_submenu_page('plugin-options', __('plugin', 'plugin'), __('am_contactlogs', 'plugin'), 'manage_options', 'contactlogs', array($this, 'plugin_contactlogs_page_handler'));
add_submenu_page('contactlogs', __('New contactlog', 'plugin'), __('Add new b', 'plugin'), 'activate_plugins', 'contactlogs_form', array($this, 'plugin_contactlogs_form_page_handler'));
}
Now it shows a menu option in the left menu of wordpress. I would like to remove this menu option and create a hyperlink on the dashboardpage to this page. If i remove the lines wordpress is telling me i have no permission to view the page. what am i missing here
So i want to remove the menu item but want to page to be accessible as a link on another page. Otherwise my menu will become very large :-).
I hope it is understandable, otherwise please ask..
If you use null for the parent_slug parameter the page won't show up in the menu.
add_submenu_page(
null,
'My Custom Submenu Page',
'My Custom Submenu Page',
'manage_options',
'my-custom-submenu-page',
'callback_function' );
The page will be accessible via any parent slug, as long as it exists:
https://yoursite.com/wp-admin/options-general.php?page=my-custom-submenu-page
https://yoursite.com/wp-admin/tools.php?page=my-custom-submenu-page
https://yoursite.com/wp-admin/index.php?page=my-custom-submenu-page
...
Or no parent slug at all (same effect as if you'd use index.php):
https://yoursite.com/wp-admin/?page=my-custom-submenu-page
But it's probably best to use admin.php for your hyperlinks (the menu item that belongs to the slug you use will be active - if you use admin.php no menu item will be active):
https://yoursite.com/wp-admin/admin.php?page=my-custom-submenu-page
I would like to add a link to the contextual links on a view block. Currently there's the "modify view" and "translate view" links.
Isn't there a way to inject it in the myTheme.theme file ? Like a preprocess ? I looked in the preprocess_view_view and there's only this in the title_suffix :
"contextual_links" =>
"#type" => "contextual_links_placeholder"
"#id" => "entity.view.edit_form:view=promotions:location=block&name=promotions&display_id=block_1&langcode=fr"
I want to add "Sort" that links to "/admin/sort/promotions".
I searched a bit and all I see is solutions talking about creating a custom module. I tried but it's way over my head with the routing and all... I just don't get it. Seems I would need to learn Drupal 8 inside out just to add that link.
I am trying to create a custom admin page in drupal 8 admin
i have create a custom module name custom_admin also I have added the below code in
"custom_admin.routing.xml"
custom_admin.contactformlisting:
path: '/admin/structure/contactformlisting'
defaults:
_content:
'\Drupal\custom_admin\Controller\AdminController::contactformlisting'
_title: 'Contact Form Listing'
requirements:
_permission: 'administer contact forms listing'
_access: 'TRUE'
custom_admin_permissions.yml
administer contact forms listing:
title: 'Administer contact forms listing'
in custom_admin.links,menu.yml
custom_admin.contactformlisting:
title: Contact Form Data Listing
description: 'This is a contact form listing page link`enter code here`'
parent: system.admin_structure
route_name: custom_admin.contactformlisting
But still revceving Page not Found can anybody help me in these
Not sure if it's just a typo above, but the file "custom_admin.routing.xml" should be custom_admin.routing.yml* (yml instead of xml). The permissions yml needs to be module_name.permissions.yml - you have module_name_permissions.yml (underscore instead of period).
I also notice some spacing issues in the routing file for _access:(again not sure if just a typo here), but yml format is very specific. They need to all be indented 2 spaces.
If it's still not working, I would suggest removing the _access property altogether from the routing yml and set _permission: TRUE temporarily, just to remove any other variables that could be interfering.
I have a view that has the following settings:
Style: Unformatted
styleRow style: Fields
...
Filters
Node: Published Yes
Node: Type = Image
Node revision: Title begins
slideshow_q
...
Fields
Node: Title Title
Image: Image Image
I also have 6 image nodes. Yet only one of them--the fifth one!--is showing up in my view. What am I doing wrong?
EDIT: here is the exported view for a closer look.
I would guess that the nodes in question are not published, or they are not a type Image, or their title does not begin with 'slideshow_q'.
Try removing the Published filter and see what the result is.
EDIT: Try removing the Node Revision filter. I thought it said Node.
I've defined a view with the CCK and View 2 modules. I would like to quickly define a template specific to this view. Is there any tutorial or information on this? What are the files I need to modify?
Here are my findings: (Edited)
In fact, there are two ways to theme a view: the "field" way and the "node" way. In "edit View", you can choose "Row style: Node", or "Row style: Fields".
with the "Node" way, you can create a node-contentname.tpl.php which will be called for each node in the view. You'll have access to your cck field values with $field_name[0]['value']. (edit2) You can use node-view-viewname.tpl.php which will be only called for each node displayed from this view.
with the "Field" way, you add a views-view-field--viewname--field-name-value.tpl.php for each field you want to theme individually.
Thanks to previous responses, I've used the following tools :
In the 'Basic Settings' block, the 'Theme: Information' to see all the different templates you can modify.
The Devel module's "Theme developer" to quickly find the field variable names.
View 2 documentation, especially the "Using Theme" page.
In fact there are two ways to theme a view : the "field" way and the "node" way. In "edit View", you can choose "Row style: Node", or "Row style: Fields".
with the "Node" way, you can create a node-contentname.tpl.php wich will be called for each node in the view. You'll have access to your cck field values with $field_name[0]['value']
with the "Field" way, you add a views-view-field--viewname--field-name-value.tpl.php for each field you want to theme individually.
Thanks to previous responses, I've used the following tools :
In the 'Basic Settings' block, the 'Theme: Information' to see all the different templates you can modify.
The Devel module's "Theme developer" to quickly find the field variable names.
View 2 documentation, especially the "Using Theme" page.
A quick way to find the template files you can create and modify for a view in Views 2.0 is to:
Edit the view
Select the style (e.g. page, block, default)
In the 'Basic Settings' block click on 'Theme: Information' to see all the different templates you can modify.
The Devel module's "Theme developer" feature is handy for seeing what template files Drupal is looking for when it goes to theme something. See the screenshot on that page for an example.
You should also check out Semantic Views. For simple Views theming, it is really handy.
One tip:
You'll likely have a number of views which require similar formatting. Creating templates for each of these views and copying them creates a nightmare of code branching - if you're asked to change the whole look and feel of the site (implying changing the display of each of these views formatted in this particular way), you have to go back and edit each of these separately.
Instead of using the views interface to select new templates for views, I sometimes simply insert some code branching into a single views file. E.g. for one site in views-view-fields.tpl.php I have:
if($view->name == 'articleList' || $view->name == 'frontList'
|| $view->name == 'archiveList') {
/* field formatting code */
} else {
/* the default code running here */
}
This then modifies the fields in the way I want only for this family of Views = articleList, frontList and archiveList - and for other views using this template runs the code one normally finds in this template. If the client asks, "Hey, could you make those pages showing the archives & that list on the front page to look more like ( ... )", it's simply a matter of my opening & editing this one file, instead of three different files. Maintenance becomes much more quick & friendly.
for me block-views-myViewName-myBlockId.tpl.php works
My shortcut option.
Go to theme.inc file in YOUR_MODULE_DIR/views/theme/ folder.
In the _views_theme_functions function print the $themes variable or put a breakpoint on the last line of the function to see the content of the variable.
Just convert views_view to views-view and __ to -- and add your template extension to get desired file name.
For example if an element of the $themes array is views_view__test_view__block (where test_view is the name of your view) then the name of the template file would be views-view--test_view--block.tpl.php.
In my opinion the simplest way to decide which template file to use for theming the views is :
1) Click on admin/build/views/edit/ViewName -> Basic Settings -> Theme
Clicking this would list all the possible template files. Highlighted (File names in Bold) files indicate which template file is being used to do theme what part of the view. After incorporating the required changes in the relevant view template file RESCAN .. now you should be able to see the changed template file highlighted .
If you want to do quick Drupal development with a lot of drag-and-drop, the Display Suite module def. is a something you should use: http://drupal.org/project/ds
According to me there are two ways to do it:
Programatic Way:
Go to edit view.
Select page/block style.
Go to 'Basic Settings' and click on 'Theme: Information' to see all the different templates you can modify.
Add the html you want to theme and print the variables of the view wherever needed
Configuration Update: The Display suite provides us an option to place your labels inline or above and add even to hide them. Custom classes to each of the view's elements can be added too.
Advanced options include:
Exportables
Add your own custom fields in the backend or in your code
Add custom layouts in your theme (D7 only)
Change labels, add styles or override field settings (semantic fields).
Full integration with Views and Panels
Extend the power of your layouts by installing Field Group
Optimal performance with Object cache (D6) or Entity cache (D7) integration