Leaderboard
Popular Content
Showing content with the highest reputation on 12/19/2013 in all areas
-
I mean the way our idol is describing it here: http://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/#entry6174 For most scenarios this is the best way for me. For bigger sites with a lot of different page types the "in main template logic" can get confusing or just too difficult. My structure is like that (simplified): /site/templates/ home.php standard.php ../tpl/ main.php ../css/ and so on. In my "real" templates (meaning PW templates) "home" and "standard" I define page parts like this (simplified): $title = $page->title; $summary = $page-summary; $body = $page->body; $contact = ""; if(count($page->contact)>0) $contact = $page->contact->title; $content = " <main> <h1>{$title}</h1> <p class='summary'>{$summary}</p> {$body} </main>"; include('tpl/main.php'); and in my main.php (simplified): <html> <head> (...) </head> <body> <header> (...) </header> <?= $content ?> <footer> (...) </footer> </body> </html> Of course there is much more. But the thing is: the main.php handles the overall markup, while the templates handle the logic. In this case I use only the standard.php file while I have more templates in PW admin for presenting different fields. In my standard.php I differentiate by querying if($page->template->name == 'location') { $content .= ...list some locations } for example.3 points
-
One interesting thing I have read about SEO and images is the way google looks at both the alt and the title tag. Generally, they look at the alt attribute most, but (and Teppo's point is well made) it scores better if it is used how it should be - a simple, readable phrase that has a direct relationship to the image content. But the other thing to note is that some SEO specialists say that if you are using a title attribute then it should not be just a repeat of the alt, but be a clear and separate title for the image. If you are putting your keywords into alt and title, therefore, you should ensure that they are a) relevant and b) different to each other. But as with every thing SEO, there are probably a thousand conflicting ideas out there, proving that there is an entire industry making money by basically guessing!3 points
-
Another one finished (only german/swiss at the moment, english is in the works): http://www.helveting.com/ Responsive (also with responsive images + art direction via thumbnail module for the slider/header images) Form Builder for applications as always, the great thumbnail module from Apeisa Thx to Soma for the always used SimpleMarkupNavigation module and countless others ;-) Perhaps worth a mention: The locations overview, a combination of a repeater and Ryan's map marker fieldtype: http://www.helveting.com/about/organisation-und-standorte/ rendered with styled Google Maps Feedback welcome2 points
-
It is a bit of an odd one this, but I can see where Martijn is coming from. You see this in surveys where your answers may be Choose "1" or "2" or "none of the above apply" Actually, the third option is a defined answer equal in weight to the other two, but to the user it is like saying "ignore this" or "deselect my first thought and move on" The use of radio buttons, as opposed to a dropdown select, is always interesting. I tend to use it where I want the user the opportunity to gaze over all the options in one go before having to make a decision. But they do lose a bit of the usability of a dropdown where you can have a default or selectable "no value" blank, if you wish. My rule of thumb is if it is complicated (like a survey) then use radios. If it is simple (Yes/no perhaps or a simple list) then a drop down is fine2 points
-
Interesting point takin Teppo. As search engine becomes smarter and more 'human', fooling search engines with simple words has become questionable. I tend to think, search engines love 'packages' of information. A good header a few good paragraphs, a good link to related material and good naming conventions for images and their an alt text. In my opinion, search engines try to find what's best for a human to read. More, it's likely that search engines recognize some kind of social aspect. Is a site friendly for colour blindness ? What do users see when they have a poor connection. How is the bandwidth. All the little bit help if you asked me.2 points
-
I open this topic because in another one (http://processwire.com/talk/topic/1732-shop-for-processwire-apeisa/) there was a discussion going on that -in my point of view- went off-topic. Here's what it's all about: Say you want to create a module that needs some additional scripts/stylesheets what is the best way to accomplish that? Right now I only know three ways (which all have their weaknesses): First: Just edit the head.inc and include those scripts in the head-tag. OK, this is pretty easy but it has two drawbacks: - The scripts are now on every page (in the front-end) - You have to edit the head.inc* Second: Include <?php foreach($config->scripts->unique() as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?> in your head.inc and add the scripts from your module with $this->config->scripts->add($this->config->urls->PaymentExample . "script.js"); This seems pretty neat because the scripts will only be included where they are needed, but: - It is not very flexible. What about in-site scripts? - You have to edit the head.inc* Third: Use the hooking- mechanism of PW by adding $this->addHookAfter('Page::render', $this, 'addScripts'); to the init- function of your module. This is the addScripts function: public function addScripts($event) { $page = $event->object; // don't add this to the admin pages if($page->template == 'admin') return; //other mechanisms to ensure the script only loads when this module was called in the front-end $additionalHeadScripts = '[myScripts...]'; $event->return = str_replace("</head>", $additionalHeadScripts.'</head>', $event->return); } Of course this approach also has its drawbacks: - It is a bit difficult - It probably makes your PW installation run a bit slower because the addScripts- Methods gets called on every page request. *Why is it a bad thing to edit the head.inc to provide scripts/stylesheets for your module? I personally think if you want to distribute a module the admin that wants to integrate this module should just hit the install button and do some configurations and that's it. This is called usability and I believe in it. In my opinion it is not user/admin friendly if you have to pack a readme file to the module that says "but first you have to alter your template file to make that module work"... That said, if <?php foreach($config->scripts->unique() as $file) echo "\n\t<script type='text/javascript' src='$file'></script>"; ?> was already in the default template head.inc file I would not hesitate one second to use the second approach for my module. Because if an admin creates his/her own template and it is not based on the default template it's his/her fault... So, what do you think? Which is the best approach for you and why? Or do you have another approach? Maybe it would also be a good thing if there was something in the API that we could use for this need. A more standardized approach?1 point
-
Words of encouragement from the Pub's amateur psychiatrist (Read best in a soft spoken, German accent) Ah, you are here because you have been reading things in this forum about pages that have left you confused, disorientated, befuddled. You thought you knew what a page was - you have been thumbing through them, folding them, studying them, wrapping things up in them and scrolling up and down them for most of your life! A page is this solid item - this great lump of data stuffed with things. But now you have come to Processwire, and everything you thought was true, simply isn't any more. For in Processwire pages are completely different - they are not great gulps of information, but tiny little things, nothing more than a link to the more interesting world of fields and templates; just a little blip of data in your huge fascinating database. Pages in Processwire are used for all kinds of things. They can be used as a marker in your pages list. They can be used as a group parent for other pages. They can be used as categories, tags or lists or users. And they can even be used for simple drop-down selects - just to supply a label and value. It can seem crazy to use such an iconic thing like a page for such a mundane and trivial task! But don't worry and fret, don't lose sleep or pace the floor as you think the reputation of the noble page is being crushed! In Processwire, they are fulfilling their duty to the full - and the more slight the task, the more they bound up to the wall and jump up and down shouting "use me, use me!" And, as a bonus, they can even be used for content - for all that stuff you thought was a page, but in Processwire isn't! So, don't be put off by the Processwire page - use it for everything! it is much smaller than you think, takes up hardly any space at all, is well behaved and only will do its thing when it is called. In fact it is hardly a page at all .... and then again, it is also so much more!! Better now? Joss Freud1 point
-
One of the problems with using Joomla on an off since, well, since it started, is that I appear to have signed up for a whole heap of sites so I could download extensions and so on. For some reason, perhaps now would be a good time to try and delete myself from a few or more of those sites...... Oh, a new little collection of PW sites will be appearing shortly ....1 point
-
What are the language settings of ProcessWire? My guess is that maybe the locale is set different from PHP when you execute the Less script inside Pw templates. See : http://www.php.net/manual/en/function.setlocale.php1 point
-
Yeah I'm also here.1 point
-
Thanks for your help. Exactly what I was looking for. Irony is that you have helped me a lot with ModX Evo some years ago and also here now.1 point
-
When it comes to the layout on the front end, well the world is your oyster. PW does not have any themes as such as with Drumlapress - instead it has a system where you can use any way you want of putting together how your site looks. You can use a framework like Bootstrap or Foundation, or you can simply hand code some html. For fun, when I wrote my basic site tutorial (http://wiki.processwire.com/index.php/Basic_Website_Tutorial) I actually used a really old copy of Dreamweaver, just to prove the point that PW is completely agnostic. Of course, this also means that if you want to use any fun JQery plugins, rather than have to create something that somehow works with a maddening API to make it even available to the site, let alone work, you just have to follow the normal instructions as if you were adding it to a static site, then bung in a bit of PW to produce the content. So, unlike the others, your hands are not tied - PW will serve up the content, it is up to you how you want to treat it.1 point
-
Yep One of the really good things about PW is that it is also a pretty good way of learning PHP! If you follow the various tutorials people have put up, copying and pasting the code where you need to, you will soon start grasping some of the more commonly used parts of PHP in websites and get a better idea of what you need to research for those bits you don't know Good luck1 point
-
@Martijn: search engines have surely improved their algorithms a lot, but there are still things that are pretty hard for them to get right. One of these is whether alternate content is really relevant to the visually impaired, another is the general subject of usability. Sure, page speed matters, but what about totally unusable navigation, unreadable font face or inconsistent UI in general? Personally I'm a big fan of trying to analyze just about any data and making educated guesses about how good it is for purpose x, but I don't think we're quite there yet. According to some experts "human factors" are nowhere near the top of the list, at least. "Social" factors sure are, though in a different meaning than what you probably had in mind.. (Actually above link kind of seems to suggest that alt texts are considered good for SEO if they contain important keywords already visible in other content. This doesn't sound like a very good thing to me, as I fear it only encourages people to use them to repeat same things they've already mentioned in body content and headlines, which in turn doesn't necessarily imply any correlation with them being useful to the visually impaired.)1 point
-
Still remember this one ? Nice one from 2003 bumped on it again today on youtube and is still fueling my emotions from end 90's when wind of life was ok. Playing it while playing with pw. Feels good in both ways. Now listen to this one. Guess Blue Cantrell sampled from Dr. Dre in their song. Nice one too. https://www.youtube.com/watch?v=X_iuSoyvExo1 point
-
Have you seen this post: http://processwire.com/talk/topic/417-extending-image-field/ It describes how you can extend it yourself to handle the extra fields.1 point
-
Dear Ryan, Please accept my appreciation on the system that you have created. Processwire is amazing. We were planning to redesign and make our Film Magazine more attractive and easy to manage, especially as it was run by a very short staff. We had been lagging behind in deadlines with each issue. We started the process about 5 months ago, when I started searching for the most suitable system to trust the work to. I have been a wordpress developer for sometime, but I did not want to take that path, frankly very annoyed with the huge amount of mostly defunct and dead plugins and other things that makes it tedious to run a website for a developer ( those are just my thoughts ). The process was gradual, and I was tremendously impressed by the conciseness of the entire Processwire system and the support forums, suffice it to say that, I did not have to ask any questions in the forums to work things out, the answers were all there. This is the first forum post that I am writing and this is after the job has been completed. I invite the community and especially Ryan to please have a look at the Magazine, its available here: PROJECTORHEAD Although it is still a work in progress, but we feel glad to release the magazine with the new issue. The magazine has been in existence for more than 2 years and this is the ninth issue. The blog section on the website is still running wordpress. I would love to hear feedback about the website, both in terms of content and design, and ideas about making it more reader friendly. We present this magazine to the community. Thank you. Suraj Prasad Web-Architect PROJECTORHEAD1 point
-
I just committed the support for variations (using repeaters): create a repeater which has title and sc_price fields add it to your product template loop your variations on product page (you can have product without variations too) Here is example code for looping the variations (or using fixed price). Repeater is called shop_product_variations: $sc = $modules->get("ShoppingCart"); if ($page->shop_product_variations->count() > 0) { $page->body .= "<p>Choose variation:</p>"; $page->body .= "<div class='variations'><form method='post' action='./'><table>"; foreach ($page->shop_product_variations as $p) { $page->body .= "<tr><td><input type='radio' value='{$p->id}' id='sc_product_id_{$p->id}' name='sc_product_id' /><label for='sc_product_id_{$p->id}'>{$p->title}</label></td><td class='price'>". $sc->renderPrice($p->sc_price) ."</td></tr>"; } $page->body .= "</table><input type='number' class='sc_qty' name='sc_qty' value='1'/> a <input type='submit' value='Add to Cart' /></form></div>"; } else { $page->body .= "<div class='price'>Price: ". $sc->renderPrice($page->sc_price) . "</div>"; $page->body .= "<form method='post' action='./'><input type='hidden' value='{$page->id}' name='sc_product_id' /><label for='sc_qty'>Qty</label><input type='number' class='sc_qty' name='sc_qty' value='1'/> <input type='submit' value='Add to Cart' /></form>"; } And example of variations on live site: http://www.martanpuoti.fi/tuotteet/mennaan-eika-meinata-t-paita-unisex/muut-tuotteet/1 point
-
Hey 12345j, are you still here? I just tried this out and fixed a bug with "$config" should be $this->config in modules. Mind if I put this on my github account? Edit: I just added a configuration setting, for defining the html tag the js script will get prepended to. Right now it will be prepended to the </head>, which might not where one wants to have it. So I added a text field where you can for example use "</body>" instead. Edit: Ok I just went and created a git repo with the updated version of this module. I also renamed the module to EmailObfuscator: https://github.com/s...EmailObfuscator1 point
-
Thanks for posting Soma, this is an interesting approach and not one I've seen before, but it looks great. The underlying concept and result is similar to the approach I usually use. Since you posted a good description, I'll try to do the same for mine. The only reason you see head/foot files in the default PW profile is because it seems to be simpler for new users to grasp. But I almost never use that approach in my own sites. Like your system, I have a main.php file which is my main markup file. But unlike your system, main.php is included from all the other template files (rather than main.php including them). The other template files focus on populating the key content areas of the site, specific to the needs of the template. Examples of key content areas might include "main" (for center column/bodycopy) and "side" (for sidebar/related info), though often includes several other identified areas. But I'll keep it simple in this case. Here's how it works: basic-page.php <?php $outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if($page->numChildren) $outMain .= $page->children->render(); // list the children $outSide = $page->sidebar; include("./main.php"); main.php <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $outMain; ?></div> <div id='side'><?php echo $outSide; ?></div> </body> </html> The benefit of this approach is that basic-page.php can setup whatever it wants in the key content areas ($main or $side) whether simple like in this example, or something much more complex. I actually prefer for the variables representing the key content areas to be optional. In the scenario above, $outMain and $outSide would have to be defined by every template or they would end up as uninitialized variables in main.php. As a result, I actually use $page as an anonymous placeholder for these variables (making sure they don't conflict with any existing field names) and then let main.php assign defaults if the calling template didn't specify one of them. For example: basic-page.php <?php $page->outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if($page->numChildren) $page->outMain .= $page->children->render(); // list the children // note: no $outSide specified include("./main.php"); main.php <?php // setup defaults when none specified if(empty($page->outMain)) $page->outMain = $page->body; if(empty($page->outSide)) $page->outSide = $page->sidebar; ?> <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $page->outMain; ?></div> <div id='side'><?php echo $page->outSide; ?></div> </body> </html> Final thing to point out here is that main.php is the only template actually outputting anything. Because basic-page.php (or any other template) is determining what's going to go in that output before it is actually sent, your template has the opportunity to modify stuff that you might not be able to with other methods. For instance, the <title> tag, what scripts and stylesheets are loaded, etc. Here's the example above carried further to demonstrate it: basic-page.php <?php // make a custom <title> tag $page->browserTitle = $page->rootParent->title . ": " . $page->title; $page->outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if(count($page->images)) { // display a clickable lightbox gallery if this page has images on it $config->scripts->add($config->urls->templates . "scripts/lightbox.js"); $config->styles->add($config->urls->templates . "styles/gallery.css"); $page->outMain .= "<ul id='gallery'>"; foreach($page->images as $i) { $t = $i->size(100,100); $page->outMain .= "<li><a href='{$i->url}'><img src='{$t->url}' alt='{$t->description}' /></a></li>"; } $page->outMain .= "</ul>"; // add a note to $page->title to say how many photos are in the gallery $page->title .= " (with " . count($page->images) . " photos!)"; } if($page->numChildren) $page->outMain .= $page->children->render(); // list the children include("./main.php"); main.php <?php // if current template has it's own custom CSS file, then include it $file = "styles/{$page->template}.css"; if(is_file($config->paths->templates . $file)) $config->styles->add($config->urls->templates . $file); // if current template has it's own custom JS file, then include it $file = "scripts/{$page->template}.js"; if(is_file($config->paths->templates . $file)) $config->scripts->add($config->urls->templates . $file); ?> <html> <head> <title><?php echo $page->get('browserTitle|title'); // use browserTitle if there, otherwise title ?></title> <?php foreach($config->styles as $url) echo "<link rel='stylesheet' type='text/css' href='$url' />"; foreach($config->scripts as $url) echo "<script type='text/javascript' src='$url'></script>"; ?> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $page->get('outMain|body'); // use outMain if there, or body otherwise ?></div> <div id='side'><?php echo $page->get('outSide|sidebar'); // use outSide if there, or sidebar otherwise ?></div> </body> </html> More than half the time, I'll actually just re-use page variables like $page->body and $page->sidebar rather than $page->outMain and $page->outSide. That way there's no need to consider defaults, since $page->body and $page->sidebar untouched technically are defaults. <?php $page->body = "<h2>{$page->subtitle}</h2>" . $page->body . $page->children->render(); But technically you've got a little more flexibility using your own self-assign anonymous variables like outMain and outSide, so figured I'd use that in the examples above. outMain and outSide are just example names I came up with for this example and you could of course name them whatever you want.1 point
-
Attached is an entire Fieldtype and Inputfield that show an example of 3 inputs for each image (title, tags and description). I've also set it up so that you can just change the schema in the getDatabaseSchema() function and it should automatically work with whatever varchar or text fields that you add. Though note that you'll want to make those changes before you create any fields with it. This works because the only place these custom fields are defined is in that schema, and everything else in the Fieldtype and Inputfield just picks it up from that schema. In the future, I will probably use this as a foundation for a more advanced image/file fieldtype where you can specify the schema from the field's configuration in the admin, rather than modifying the code. But figured this would be a good example for what you asked for. Ryan FieldtypeImageExtra.zip1 point
