Search the Community

Showing results for tags 'markup'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Welcome to ProcessWire
    • News & Announcements
    • Showcase
    • Wishlist & Roadmap
  • Community Support
    • Getting Started
    • Tutorials
    • FAQs
    • General Support
    • API & Templates
    • Modules/Plugins
    • Themes and Profiles
    • Multi-Language Support
    • Security
    • Jobs
  • Off Topic
    • Pub
    • Dev Talk

Found 12 results

  1. Docs & Download: rockettpw/markup-sitemap Modules Directory: MarkupSitemap MarkupSitemap is essentially an upgrade to MarkupSitemapXML by Pete. It adds multi-language support using the built-in LanguageSupportPageNames. Where multi-language pages are available, they are added to the sitemap by means of an alternate link in that page's <url>. Support for listing images in the sitemap on a page-by-page basis and using a sitemap stylesheet are also added. Example when using the built-in multi-language profile: <url> <loc>http://domain.local/about/</loc> <lastmod>2017-08-27T16:16:32+02:00</lastmod> <xhtml:link rel="alternate" hreflang="en" href="http://domain.local/en/about/"/> <xhtml:link rel="alternate" hreflang="de" href="http://domain.local/de/uber/"/> <xhtml:link rel="alternate" hreflang="fi" href="http://domain.local/fi/tietoja/"/> </url> It also uses a locally maintained fork of a sitemap package by Matthew Davies that assists in automating the process. The doesn't use the same sitemap_ignore field available in MarkupSitemapXML. Rather, it renders sitemap options fields in a Page's Settings tab. One of the fields is for excluding a Page from the sitemap, and another is for excluding its children. You can assign which templates get these config fields in the module's configuration (much like you would with MarkupSEO). Note that the two exclusion options are mutually exclusive at this point as there may be cases where you don't want to show a parent page, but only its children. Whilst unorthodox, I'm leaving the flexibility there. (The home page cannot be excluded from the sitemap, so the applicable exclusion fields won't be available there.) Sitemap also allows you to include images for each page at the template level, and you can disable image output at the page level. The module allows you to set the priority on a per-page basis (it's optional and will not be included if not set). Lastly, a stylesheet option has also been added. You can use the default one (enabled by default), or set your own. Note that if the module is uninstalled, any saved data on a per-page basis is removed. The same thing happens for a specific page when it is deleted after having been trashed.
  2. Hi all, I am new to PW and building up a website for a customer and have some problems with structuring my project: On my main.php file I have a main-tag where I wan't to echo the region called 'content'. But the problem is that the markup inside this wrapper should be variable.Example: I have a page where all the news previews are outputed like in a normal news app--> no additional markup is needed. But on "home" I want to have different sections with content --> <section> <div class="slider"> <!--here i want to have some filtered news articles--> </div> </section> <section> <div class="news"> <!--here i want to have some news articles but with another filter--> </div> </section> How can I realise that? It has to be like that for responsive purposes. Is it maybe possible to create and echo regions inside the "parent region"? Cheers and thank you for your help
  3. As a graphic designer I like the new options to output markup with the templates (region function and regions markup strategy) but testing them I think they could adapt a little more for ease of use. In this proposal I modify the syntax and the way of assigning the values, while I try to maintain the concept. Next the common example, in "_main.php" <!doctype html> <html class="no-js" lang=""> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <title></title> <meta name="description" content=""> <meta name="viewport" content="width=device-width, initial-scale=1"> <!--[pw headseo]--> <!--[/pw]--> <!--[pw headstyles]--> <link rel="stylesheet" href="css/normalize.min.css"> <link rel="stylesheet" href="css/main.css"> <!--[/pw]--> <script src="js/vendor/modernizr-2.8.3.min.js"></script> <!--[pw headscripts]--> <!--[/pw]--> </head> <body> <!--[pw header]--> <h1><?php echo $page->title(); ?></h1> <!--[/pw]--> <!--[pw body]--> <?php echo $page->body(); ?> <!--[/pw]--> <!--[pw footer]--> <!--[/pw]--> <!--[pw footerscripts]--> <script src="js/jquery.min.js"></script> <!--[/pw]--> </body> </html> then in the template file "home.php" <!--[pw headstyles+]--> <link rel="stylesheet" href="css/home.css"> <style> body { padding-top: 50px; padding-bottom: 20px; } </style> <!--[/pw]--> <!--[pw head+]--> <h2><?php echo $page->headline(); ?></h2> <!--[/pw]--> <!--[pw footer]--> <h3>About Homepage</h3> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec efficitur dignissim nisi nec consequat.</p> <!--[/pw]--> Well I'm not a programmer, I hope you understand the above. But the idea is: Using html comments for regions definition, this is a standard in html, and not interfere with the DOM or with the page structure, allowing using it in document areas that are not visual. The current option basically is to use DIV but this is not correct in areas like the head tag. Using the open/close tag system allow the use of IDE features for html as auto-completion, code coloring, code validation, visual previews and more. Allowing populate the initial values for regions without variables concatenation and with the previous advantage (auto-completion, code coloring, etc) The pages can be render without additional Ids and class, maybe useful for debugging and can be cleaned in production with something like $config->cleanRegions = true; It can support the current prepend, append, before, after etc regions strategy, I think its a mix of the current Region Markup. As I said I am not programmer but I think it can be implemented using Output Buffering ob_start (); ob_end_clean (); capturing the code between open/close comments tag and assigning them to the corresponding region ... If someone likes and have time to analyze and improve this idea, are welcome because I don't know how to implementing it .. sorry
  4. Hello Forum members. I just wanted to confirm with you PW gurus on here that i got the thinking behind regions in the latest blog post right: https://processwire.com/blog/posts/processwire-3.0.49-introduces-a-new-template-file-strategy/ So my understanding from the quick glance of the article is that if i were to use the new regions functionality it would in simple terms work like this: The referenced HTML in any of my other page template files would be inserted at the designated place in the home.php template file instead of replace it with all HTML in that page template file that was requested ? And the home.php template file would become sort of a View, that used HTML from the other templates files to change acording to the needs? So that i would only need to put the HTML that changed in my other page template files and have the "full" HTML markup in the home.php ? I just wanted to see if i got it right. Thx in advance.
  5. At page editor level I need to place a piece of code which is unique to that page. This is the code: <healcode-widget data-type="class_lists" data-widget-partner="mb" data-widget-id="xxxxxxxx" data-widget-version="0.1"></healcode-widget> This code pulls in data from a third-party site. The Body Field won't accept this code. I could place this in the template file but for that I'd have to crate a separate template file for each page. I'd rather use a common "basic_page" template file for most pages. Also, I would like to give the client the ability to change/edit code when necessary if it is at page editor level. Is there any way to achieve this? Thanks.
  6. Why does the forms API use lists - ul, li - to style forms? It makes them much harder to control with CSS. Why not something like this? <style> .field { float: left; width: 100%; } .inputfieldheader { float: left; width: 100%; } .input { float: left; } </style> <form> <div class=field> <label class=inputfieldheader>Field one</label> <input class=input> </div> <div class=field> <label class=inputfieldheader>Field two</label> <input class=input> </div> <div class=field> <label class=inputfieldheader>Field three</label> <input class=input> </div> </form>
  7. So I have recently integrated Soma's super awesome JQueryDataTables plugin and have used it in a process module I made to handle sending newsletters. However, I'm not sure how to go about moving the table on the module admin page. No matter where I call the table markup in the ___execute() method it shows up at the top of the page. What would be a good away to go about moving this to the bottom of the page instead? Is there a way to do this as I build the form and add the fields? Or do I just need to make some custom css file and include it in the module? Thanks in advance for reading **InputFieldMarkup is the winner. Never seen it before, it's so cool! These guys have thought of everything!
  8. Some sites need widgets, as they have been called in some systems; a widget can be almost anything, like: tag cloud mini calendar menu quote rotator free text social sharing search contact info map This is a simple way to create widgets that can be shown in multiple "areas" of a page, as well as on specific pages. In this particular method you would need to setup each widget type you want and then determine how best to accept any necessary user input like content, pages select (like for a menu) or settings. This example uses include files for each widget type, and the name of the include file would match the name of the widget type, which is also a page field. In this example, I'm also using ListerPro to provide a widget management page. Fields The main fields used on this widget example are : title widget_location (page select - options in this case are footer and sidebar) widget_type (page select, you would configure your widget types as selectable options) pages_select (would be used for multiple pages and might apply to a menu widget) body - used for plain widgets selector (selector inputfield, used for telling the system where to show the widget) text_structured - for this i'm using a YAML field, but it could just as easily be a table; would depend on what you want to store; YAML would allow this single field to be used for varying requirements based on the widget type, but would be harder to validate and prone to user error; icon - a page select for an optional icon which is being used in the template, and would be shown as part of the widget. Files for each widget type you want to allow users to select from, you would need to create an include file with the markup for that widget, and then add that widget to the list of available widgets. here is an example for a site with several widget types: Selector & Output wherever you want to include the widgets (footer, sidebar etc.) you would run a $pages->find and then foreach through the widgets (in this case finding all footer widgets). In this case the (incredibly amazing new) selector field would be specifying what pages to show the widget on. We assume that most widgets won't have a selector specified, and will default to show the widget. if a selector is specified, we can check to see if this page fits the selector by using the $page->is($selector) syntax. <?php $widgets = $pages->find("template=widget, widget_location=footer, sort=sort"); foreach($widgets as $widget) { // check if the selector field is in use and if so, see if this page is supposed to display it: if( $widget->selector) { if( !$page->is("$widget->selector") ) continue; } $widgetType = $widget->widget_type->name; $include = file_exists("./inc/widget-{$widgetType}-foot.inc") ? "./inc/widget-{$widgetType}-foot.inc" : './inc/widget-footer.inc'; include($include); } ?> this example also has a fallback file in case the widget type is not specified, sort of a default. the widget's .inc file will be unique to your design and how you have it setup.
  9. Just in case anyone else is interested who like me didn't know until now, it looks like [goodrelations](http://www.heppnetz.de/projects/goodrelations/) is a valuable 'add on' to the use of schema.org. I know nothing about goodrelations except that it appears to be blessed by Google, Yahoo, Microsoft (I think (pretty sure I found them via a link within the schema.org site and once I visited the goodrelations site I noticed they say they are used by Google and Yahoo)). First read suggested it's something like an extension library for ecommerce markup, but don't quote me on that I only skim-read a page. Just wanted to note it here in case it's helpful to you.
  10. In another topic Ryan introduced a simple module to extend the functionality of the image input field. I want to go a little bit further by extending the description textarea with the usage of the Markup fields and editors, configurable in the image extra input. I tried to copy some parts from the other input fields but don't get it to work properly. In the end I would like to have an image input field with title and description, where the description should use markdown extra and the ace editor textarea field. Anyone who can help me with that?
  11. Hi all, Let's say I want a landing page for a process module. If I wanted a form on the landing page - InputfieldForm comes to mind If I wanted a table - MarkupAdminDataTable However, on that page, I don't want a form nor a table. I just want my plain HTML to be rendered. I have no need for Inputfields on this page. Next, I look at InputfieldWrapper - But the docs say: Not my intended question, but I don't get this bit "but you can set a value...". How? I tried different stuff without success. Final up (to the best of my knowledge) is InputfieldMarkup. This code does work: $test = $this->modules->get('InputfieldMarkup'); $test->value = "<p>My test HTML output</p>"; //return $test->renderValue();//doesn't work. Markup not output return $test->render();//works fine I get my HTML output in the right place in my module landing page in the PW Admin without any extraneous markup. <div id="content" class="content"> <div class="container"> <p>My test HTML output</p> </div> </div> <!--/#content--> But is this the way to go? The name of the class sort of suggests that it should be used with Inputfields. If I try to add my HTML independent of these methods, the markup is not output in the right place in my module landing page in the PW admin, i.e. between the <div class="container"></div>. It will be thrown to the top of the page, somewhere weird like before the <body> tag. So, am I on the right track here or there is a "more appropriate" way? By the way, I tried to use renderValue() but it doesn't output anything? What's the use case for this method? The docs say: I have studied some other modules but have not seen something similar to this sort of landing page. Thanks.
  12. Hi guys.. I was wondering.. How do I render or output simpel <input> markup?? The list output that InputfieldForm makes is tomutch.. Im loading a template (without file) and I want to output the same fields as a form in the frontend.. Thanks for all your work...