Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 06/16/2014 in all areas

  1. Hi. (My first post in this forum after creating my first site with Processwire ) Only to let you know that the u-nikos's nginx configuration works perfect with Processwire 2.4 I think you can add "official" support and link to his comment for the configuration. I had doubts about how difficult it would be at the beginning and maybe there are people in the same position without knowing that it's really easy to make it works. I'll work a little more with nginx caching (or microcaching). I'll let you know if I do some advances in this area. Best
    7 points
  2. There's a permission for viewing a page and a permission for editing a page. Assigning the page edit permission to a role means they see the Pages page in the admin. There are situations where I don't want them to be able to see that (custom intranets). It would be nice if it was possible to have a separate permission to decide whether or not to show that page. There is a way to code around it in the admin template and only show it for roles that I specify, but it would be nice if there was a way to do it with permissions.
    5 points
  3. After months of silence on the forum I've decided to speak out and introduce a brand new admin theme for ProcessWire 2.4.x I've made the theme initially for our internal business project and I've decided to share it with you all The theme itself is designed only for ProcessWire 2.4.x and up because it's wrapped as a module (new theming design approach introduced in ProcessWire 2.4) and it also has it's own options you can configure. It has all the bells and whistles as Default Admin Theme of PW 2.4 as well as some of my own You can download it from here: https://github.com/nvidoni/AdminThemeModesta and please let me know of any mistakes you find during your workflow... Changelog: v1.0.1 Added unpublished pages status icon next to username (fires modal window with unpublished pages list that you can edit) Improved PageList (children are more indented with arrows before them, hidden pages have more lighter color and icons have more darker color - by suggestion from Martijn Geerts) Other CSS improvements UPDATE: You can find version compatible with Processwire 2.4.4 and up on dev branch: https://github.com/nvidoni/AdminThemeModesta/tree/dev and also let me know about any mistakes that should be fixed. Dev version isn't updated to v1.0.1 yet because of strange problem with theme not switching right (doesn't activate) - it started to happen from 2.4.5 dev version of PW...) and it seems it happens only in Windows environments...), hopefully we'll fix this soon. To sum it up and let the images do the talking, here we go:
    4 points
  4. I would like to present to you our (the Agency I work for) so far largest Processwire project, that I've built. We've launched it a few month ago, but I had allways forget to post it here. It is a campaign-website of various food-processing companies, located in the northern Germany. The purpose of the site is to present diverse jobs, apprenticeships, traineeships and study programs, which are avaiable in the companies to a wide crowd of young people. On this central point the companies can show how versatile the opportunities in the food-processing industry are. The site is not responsive, but has an alternative Mobile View, which will be displayed, if a "Mobile"-Device/User Agent is identified. Finally, one more big thank to teppo, for his essential advice to make the scaled images happen. foodstarter.de
    4 points
  5. Hi Bacelo, Thanks and sorry for my late reply. This could be done pretty easy with some custom coding. How would you integrate this into the module? I want to optimize and rewrite the module in the coming weeks. Cheers
    4 points
  6. This is really rough, but I have tested it and it does work $p = $pages->get("/test/"); $rf = "repeater_test"; //repeater field name $ptf = "pagetabletest"; //pagetable field name $ptt = "basic-page"; //pagetable template name foreach($p->$rf as $r){ $npt = new Page(); $npt->of(false); $npt->template = $ptt; $npt->parent = $p; foreach($r->fields as $f){ $npt->$f = $r->$f; } $npt->save(); $p->of(false); $p->$ptf->add($npt); $p->save(); } The key thing is that for this to work as is, the repeater field must include a title field, because this is used to generate the names of the child pages for the pagetable entries. You could of course manually add a title field in the loop when creating the $npt page. EDIT: You can ignore the need for a title by making the title hidden and not required in the context of the pagetable template and setting a value for the automatic page name format when setting up the pagetable field. For this to work, the pagetable field must be already set up and ready to go. If I had more time today, I would have enhanced this a little more regarding the title/name issue, but hopefully it should get you going.
    4 points
  7. And I watched the game with my girlfriend who is German Lot's of world cup ahead still
    2 points
  8. Congrats to all Germans, you guys played good!
    2 points
  9. I have build another non-profit website http://www.fmgcs.com with ProcessWire 2.4 completely free! This my community website which I redesigned and hookup with ProcessWire. Before it was static html pages. I have spent quit a bit of time on designing and customizing templates. Please provide your feedback as you normally do. Thank you!
    1 point
  10. This solution from diogo looks clean and logical: https://processwire.com/talk/topic/1074-get-total-pages-pagination/?p=9411 What have you tried that didn't work? You can also get the count of pages like this: $num_pages = $pages->count("selector"); Then obviously divide this by the number of items you are displaying on each page and then ceil() the result. Although this option would require a second query to the database, so go with the first option if you can.
    1 point
  11. @Diogo...when you come out of hiding , commiserations...Silly Pepe! (but naughty Müller ) .....
    1 point
  12. There was a way to hide the two menus that popped up for non-superuser folks. In sidenav.inc in the admin template module, just at the start of the function I added this: if ($p->name == 'page' && !wire('user')->hasRole('superuser') || $p->name == 'setup' && !wire('user')->hasRole('superuser')) { return ''; } For some reason, doing isSuperuser() didn't work in this case. If it works for someone else using wire('user')->isSuperuser() then it may be because of some overridden permissions in one of my modules I guess. It's a fairly easy workaround, but not particularly futureproof!
    1 point
  13. Short tip Use the ajax powered search to find pages you want to edit—it's a super-fast way to get around the admin. Longer (but same) tip I was on the cusp of not writing this because it is likely so obvious to so many, but just in case you are like me in terms of navigation in the Admin for editing pages... In PW 2.4 the new search makes finding pages lightening fast. While some themes from before 2.4 was released display recently edited pages to help speed navigation, the new default theme in 2,4 doesn't; and I missed that a bit. But the new search is super fast so now whenever and wherever I am in the Admin, if I want to edit a page I just type in the search box, it ajax-pops, one click and I'm in the page ready to edit—no need to visit the page tree Thanks to Ryan and crew for this small but great advance OK, back to work.
    1 point
  14. Names should be reasonably safe - it's a marginal case where two developers both decide to add a template named "blogpost", and it won't work either way, since you can't have two templates with the same name in the first place, so whether or not a GUID or some other new identifier enables you to identify the referenced template, you're still stuck with a problem that cannot (and should not) be solved. The system makes assertions for every possible type of migration, ahead of attempting to apply them - for example, "add template" will abort the migration process if a template with the same name already exists, etc... so it's already reasonably hardened against poorly coordinated changes. It's not intended (or expected) or designed to deal with poorly coordinated changes - it's not a "version control system", it can't "diff and merge" database changes or anything of that sort. What should work though, is if two developers independently add non-conflicting fields and templates, after coordinating and planning their work properly, and you'd be able to merge all the changes two ways. That's really all I was expecting or hoping for. It will permit other changes, like re-ordering of fields in a template, but the last applied order "wins", there is no (worthwhile) way to merge those changes. > I'm guessing you'd convert a template_id to a template name, and a parent_id to a page path Exactly right > You are right that without knowing what the properties mean ahead of time, you'd probably need some interface that externalizes those values to something considered more portable Probably the simplest (perhaps the only?) solution is to add hooks, so that field types can replace foreign keys with names or paths, and vice-versa. It makes me wish though, that field values containing e.g. template/page/field IDs were identifiable as such... this could be done in at least three different ways: Foreign key values could be somehow identifiable as foreign key values themselves - e.g. using some kind of value-type or value-object, or a URI scheme of some kind, like for example "pw://template/123" rather than simply "123". Foreign key values could be made globally unique, e.g. using GUIDs, so that when you encounter a GUID, you can go back to the ProcessWire API and ask for the resource with that GUID, whether it be a Template, Field, Page or some other PW type. Adding some kind of "schema" to Page models - e.g. allowing you to define what you're storing; so you would still be able to store an integer of course, but there would be some way to define what datatype you're storing, e.g. Template ID or Field ID, etc. I think every approach would have it's own advantages and drawbacks. A URI scheme would be very developer-friendly, since URIs would be easily readable in var_dump() etc... GUIDs would have advantages in terms of data portability in general, since any resource created on any system would be unique identifiable - this would help in the case of migration and import/export of any type of resource in general... Adding an actual schema to Page models might be the most complicated solution (for developers) and I'm not sure if it has any advantages over the other two. Thoughts?
    1 point
  15. Thanks for the kind words. I'm glad, that you like it. The next sites will come soon.
    1 point
  16. @soma Changed it to "extends WireData implements Module". And changed version to 1.0.0 like mentioned before but somehow forgot. @tobaco: Should work now
    1 point
  17. Great way to setup new languages! ot: which theme do you use in your screenshots? thanks!
    1 point
  18. Github issue opened: https://github.com/ryancramerdesign/ProcessWire/issues/520
    1 point
  19. Hi Adrian, Thanks for your suggestion, it makes totally sense - will update the module later this week. The reason I've chosen to add this setting is that the color has to be set with javascript (jqplot) so it can't be controlled with CSS. The bar graph colors could be changed with CSS, but of course the colors should match by default! Cheers
    1 point
  20. Thanks Adrian for looking into it and tracking down the bug. As efficient as always! You've saved me many times before. I will try your hack while Ryan gets a chance to fix this. And yes, I would appreciate it if you could open a bug report on GitHub as I'm certain that you will explain it a lot better than I possibly could.
    1 point
  21. I finally found time to try out this module. Congrats to all for the dedication, collaboration and hard work in creating this needed tool. A very useful module.
    1 point
  22. If you use others finds on same page with limit, you need to add start=0 to the conflicting find.
    1 point
  23. Could be totally off here, but have you tried start=0 in the selector in your hanna code?
    1 point
  24. Although I would have liked to see England win, for me I was more interested in 'how' England would play. I have never been prouder! So many positives and so many things to hope for for the future. When is the last time you saw England play attacking football and not just sit back? When is the last time you saw England actually bring the ball forward through passing right from the goalie to the front rather than hitting the customary long passes? There's so much to look forward to; well-done lads! Congrats to the Azzurri
    1 point
  25. Sad to see England lose last night but I thought there was a lot of positives. They at least deserved to draw. Stats speak for themselves: England Italy 18 Total shots 12 8 Shots on target 5 8 Fouls 12 48% Possession (%) 52% 9 Corners 2 3 Saves 7 0 Offsides 7
    1 point
  26. @Jonathan: Many thanks for this nice module. I have played around with it the whole evening. The JpegOptim runs smoothly together with the ImageSizer and with the ImagickResizer. Following are some suggestions for you. If you find something useful, please feel free to take and implement it: The ImageSizer supports unlimited individual options for thirdparty modules, but it isn't documented actually. You can add any assoc option to the images $options array in templates. But you need to avoid overriding the core ImageSizers options. Therefor I have prefixed all options from JpegOptim with a jo, followed by the initial option name in camelcase style. Now the options are parsed in this order: default settings, config page settings, template / image-options settings! Example that overrides the default setting and custom setting for quality and threshold: $options = array('joQuality'=>85, 'joThreshold'=>20); $image->width(300, $options); I have introduced an option that temporary suppresses the use of JpegOptim on a per image basis: $options = array('useJPEGOPTIM'=>false); $image->width(300, $options); Also I have played around with the option for lossless optimization, but this seems to be nearly useless (not lossless ) because it produces the same result like quality 100 and threshold 1. I have left it in the code, just for documentation. I don't have added / tested these enhancements with the pageimage::optimize hook. So if you want to use some of the above you need to test / implement it there too. I have found out that the JpegOptim produces best results and also mostly smaller results if the GD or Imagick source is rendered with 100% quality. If you render them with e.g. 80% quality, the resulting filesize from JpegOptim is slightly higher (sometimes). This can be due to more jpeg artefacts in the result from GD or Imagick Also it seems best solution to use strong sharpening (over sharpen the resized variation, what is the source for JpegOptim). $options = array('quality'=>100, 'sharpening'=>'strong', 'joQuality'=>80); $image->width(300, $options); Different tests and results can be viewed here: http://images.pw.nogajski.de/jpegoptim/ PS: as I have explained in my previous post it would be nice to keep IPTC if populated PPS: here is the code that helps testing: https://gist.github.com/horst-n/4757d5a34f2278657b6d#file-jpegoptim-testroutine-php
    1 point
  27. Hello Martijn, i did something similar as my first attempt to a pw module. Now i discovered yours. My module adds icons to the page actions (requires pw-dev labeled 2.4.4) and does not add js. It's a very quick and dirty module which uses the fotn icons of the wire core. Please check it out on github and let me know if it can be useful to onyone except me. https://github.com/pine3ree/AdminPageIcons kind regards, PS the pw project leader and this community are the kindest i ever found in web development.
    1 point
  28. InputfieldSelector is the query builder. PW now has Selector fieldtype and inputfield in a core. That means you can add it to any page, and then you have it's selector value available in your templates. There it is reasonable simple to use that selector to build table and pagination for that data (maybe using jquery datatables and like). I don't think Lister has been develop at all front end in mind, so while it might be possible to it offer a "public view", I am not sure if it's good thing (it is obviously already quite a complex module). I think it could easily end up for something that views is for Drupal, and I remember I never learned that tool (it probably is huge productivity boost for those who can handle it)... InputfieldSelector of course misses the "columns" part, ie. choosing which fields to show. You cannot have it all.. or can you?
    1 point
  29. Hey Jonathan, Thanks for this. I have just done some initial testing and it's working fine. I haven't yet done any comparisons with GD or Imagick to see if it is any better size/quality wise, but you sound convinced, so I am looking forward to analyzing more. One thing I did notice is that the ".jo" files will be left behind after deletion of the initially uploaded file. It is easy to extend Pageimage::isVariation to handle these. Horst did it with the PIM module and I did it with ImageRasterizer. EDIT - any thoughts in incorporating http://optipng.sourceforge.net/ (or similar) as well for PNGs?
    1 point
  30. I've been working hard on this module this week, and so far, so good - it's now recording and can repeat most changes to Fields, Templates and Fieldgroups. One remaining issue is foreign keys... some field types store Template IDs, Page IDs or other types of ID within the Field data. For the known field types such as PageReference, I can handle those cases explicitly, but for third-party types, there is no saying what they're storing, where, how or when. The only real solution I can think of is some kind of hook that permits other modules to support this module explicitly, by implementing methods that clean up foreign keys and replace them with names, and vice-versa... but that's not really elegant and the module won't work generally with every third-party field type out of the box. Any thoughts?
    1 point
  31. PW 2.4.4 on the dev branch...
    1 point
  32. @pleini Since you can create whatever fields you want you can also create whatever variants you want. On your template (not template file) you might want to have different tabs for different devices. However, since you want to have exactly the same data in all devices (wise choice), there is no need. You can do this as part of your template file, which is far more useful. Then the user does not have to worry about devices, the template files will sort that out. You can also use bits of php - so, for instance, you might want to break an article up into a series of iPhone sized swipeable pages, but just for phones. So, you use a bit of php to break your text up into the right sized junks and then use some sort of content slider to display them. On a Desktop, it would just show as one page. But this is all work you can do in your template files while leaving your templates/fields uncomplicated. I don't think Bootstrap has the equivilent of interchange, but I am sure there are plenty of jquery plugins out there that you could use. like response.js http://responsejs.com/
    1 point
  33. @Ivan: but you can tell the server if you want him to know it: https://github.com/serbanghita/Mobile-Detect
    1 point
  34. Hello, I've made this into a module and posted it in the Modules section (here).
    1 point
  35. This is my first module, so be easy on me! I am sure there was a faster and better way to do it, but this is what I have so far and it works pretty well! I figure by showing it, one of you may see a way to make it better! To use it, just make a hidden "csv" page in your root and add at least one csv item as a child. The children will need to have a "csv" template that has a csvFile field, and a csvDatabaseTable field. (I am thinking about adding a third one for csvDelimeter.) Also, I added a new admin page called "Read CSV files", and selected this module as the process. This reads all the children of that csv page, right now I just look up the csv page by id, so be sure and change that to hook it up to the correct page, and puts the content of the csv files into the database table listed on the child. (emptys the table first.) As of right now, the database table needs to be created in advance with the correct number of columns listed in the csv file. How much more work do you think I need to add in before it is worth listing as a public module? I just have never done one and was not sure! Thanks! Here is the page output: Importing All CSV files under csv page (id=1082) Searching for available files: Found: 1 Importing (csvFile.csv) into (csvDatabaseTable) imp row 2, imp row 3, imp row 4, imp row 5, imp row 6 Import Complete! Here is the code: <? class ReadCSV extends Process { public static function getModuleInfo() { return array( 'title' => 'Read CSV', 'summary' => 'This Module Reads the csv files under the csv page and inserts them into a database table. (Finds children of page id=1082)', 'version' => 001, ); } public function execute() { $ReturnHTML = '<p><b>Importing All CSV files under csv page (id=1082)</b></p>'; $ReturnHTML .= '<p>Searching for available files:</p>'; //find all csv files that are below the csv page. (Have it's id as their parent) $matches = $this->pages->find("parent=1082"); //Must spesify $this in a module. The following method also works: $matches = wire("pages")->find("parent=1082"); $count = count($matches); if($count) { $ReturnHTML .= "<p>Found: $count</p>"; foreach($matches as $m) { $csvDelimeter = ','; $csvEnclosure = '"'; $csvPath = '../..' . $this->config->urls->files . $m->id . '/'; //Format: ../site/assets/files/1083/ can also use $config->paths->files. (I added the ../.. to get out of the modules and sites folder.) $csvFullPath = $csvPath . $m->csvFile; $ReturnHTML .= "<p>Importing $m->csvFile into $m->csvDatabaseTable</p>"; //clear out the current database $sql = "TRUNCATE TABLE `$m->csvDatabaseTable`"; $database = $this->wire('database'); $database->exec($sql); //open csv ini_set("auto_detect_line_endings", true); //this is required. I think they are creating the csv on a mac or linux is the reason. $row = 0; $autoid = 1; if (($handle = fopen($csvFullPath, "r")) !== FALSE) { while (($data = fgetcsv($handle, 0, $csvDelimeter, $csvEnclosure)) !== FALSE) { $num = count($data); $row++; //$ReturnHTML .= "<p> $num fields in line $row: <br /></p>\n"; $allData = ''; //this holds the value string. (cell data.) for ($c=0; $c < $num; $c++) { $allData .= '"' . $data[$c] . '",'; } //insert the data if($row == 1){ //skip row 1. Instead of reading the column names, I am just inserting the data so order is important. //echo "<p>Skipping the first row.</p>"; } else { $allData = trim($allData, ','); //trim the trailing , off. $allData = $autoid . ',' . $allData; //add an extra column for the auto id column //insert into db $sql = "INSERT INTO $m->csvDatabaseTable VALUES ($allData)"; $database = $this->wire('database'); $database->exec($sql); $ReturnHTML .= 'imp row ' . $row . ', '; $autoid++; } } //end loop through spreadsheet rows fclose($handle); $ReturnHTML = rtrim($ReturnHTML, ', '); $ReturnHTML .= '<p>Import Complete!</p>'; } //close open csv } // end for loop through pages } else { $ReturnHTML .= "<b>Sorry, no results were found.</b>"; } return $ReturnHTML; } // end of execute function } //end of class ?>
    1 point
  36. Table Use this for tabular data, like rate tables or other things that you might typically represent in a spreadsheet. Use it for situations where you don't need the full-blown flexibility of repeaters, as it's technically more efficient with far less overhead than repeaters. Something like the Events Fieldtype could be very easily re-created via a Table field, but the potential uses are far broader. But for the most part, think tabular data when it comes to the Table field. Multipliers This is good for when you need a range of values (whether text, textarea, numbers, dates, etc.). If you are using repeaters with just one field in them, you might be a lot better off with a Multiplier. Like the Table field, Multipliers are very efficient and low overhead relative to something like Repeaters. Use Multipliers when you need to repeat a single input multiple times, optionally with a min and max number of inputs. Lets say you are building an employee directory, and each employee has between 1 and 3 email addresses. Rather than using 3 separate email fields, you would use 1 multiplier field and specify min=1 and max=3. Repeaters These are infinitely flexible in terms of what they represent, but each row of values is technically a page in the system. As a result, with the flexibility comes significant overhead. This is really only an issue when the quantity of repeater items gets high, or when you have lots (thousands) of pages using repeaters. I recommend repeaters for setting up things like homepage carousels. For example, if you go to the Villas of Distinction homepage, there are 3 separate repeaters in use on that page, each holding a photo, title, description, link. The client can have as many items in each of those sections as they want. Currently it looks like the first repeater as 6 items, the 2nd has 2, and the 3rd has 6. The possibilities of what can be represented with repeaters is endless, but look for potential alternatives when dealing with large quantities (whether large quantities of repeater items, or large quantities of pages using repeaters). PageTable This is one of the ProFields that is available for free (thanks to Avoine sponsorship) on the ProcessWire dev branch. Meaning, it'll be available for everyone to use as part of the core in ProcessWire 2.5. And you can use it now if you don't mind running the dev branch. PageTable has all the flexibility of repeaters, but with lower overhead from the admin/input perspective. Rather than trying to bundle all the inputs on one screen, PageTable shows you a table of items and you click on the item to edit it in a modal window. This enables it to be a lot more efficient from the admin UI perspective. It's also more flexible than repeaters are in terms of where you store your items. PageTable lets you choose where they should live, whether as children of the page being edited, or as children of some other parent page you designate. They might be a little more work to setup than repeaters, but I think that most situations where you need the flexibility of repeaters may be better served by PageTable. PageTable still can't compete with the speed and efficiency of Table or Multiplier, but consider using PageTable anywhere that you might have used Repeaters before. Repeaters and PageTable are fundamentally different from the admin UI/input perspective, so you'd want to compare them yourself to see what suits your individual input needs better. PageTable involves more clicking to create and edit items, making Repeaters potentially faster for entering data rapidly. But PageTable will scale much further in the admin UI than Repeaters will, so I would personally favor PageTable in more situations than Repeaters.
    1 point
  37. Once this idea is proven and stabilised, would it be a core module candidate?
    1 point
  38. Thanks for mentioning this, Soma. Looks like I'll have to take a closer look at the new format.
    1 point
  39. Nice site! Just because I'm feeling super helpful, attached is that homepage image after I ran it through https://tinypng.com/ - much smaller (79% smaller in fact!) and there's only very slight differences as far as I can tell - they're there if you compare them side by side, but less obvious if you view this one on its own.
    1 point
  40. I agree — ProcessModules are the way to go. They might look intimidating at first, but if you start with a very simple example, they really are very easy. Here is a super simple example that lists all pages with the template "news". (I'm sure there are others out there, but it only took a few minutes to write so...) <?php /** * Simple Process Module Example. * This is a very basic example to learn from. * I have no intention of expanding on this sample module. * * @author renobird * * ProcessWire 2.x * Copyright (C) 2011 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * http://www.ryancramer.com * */ class SimpleProcessModule extends Process { public static function getModuleInfo() { return array( 'title' => 'Process Module (basic example)', 'summary' => 'A very simple process module as an example on how easy they are to create.', 'version' => 100, 'href' => '', 'permission' => '' ); } public function init() { // initialize the parent parent::init(); } public function ___execute() { // Find some pages $items = $this->pages->find("template=news"); /** * Create a table to display results * There are other ways to do this using MarkupAdminDataTable module, but let's keep this simple for now. */ $out = "<table width='100%'>"; $out .= "<thead>"; $out .= "<th>Title</th>"; $out .= "<th>Date Created</th>"; $out .= "<th>User</th>"; $out .= "<thead>"; $out .= "<tbody>"; // If $items pageArray is not empty if ($items->count() > 0){ foreach ($items as $item) { $out .= "<tr>"; $out .= "<td><a href=". $this->config->urls->admin . "page/edit/?id=" . $item->id .">" .$item->title . "</a></td>"; // title $out .= "<td>" . date("F j, Y", $item->created) . "</td>"; // date created $out .= "<td>" . $item->createdUser->name. "</td>"; // user that created $out .= "</tr>"; } } else { // empty pageArray message $out = "<tr><td>No pages matching your criteria were found.</td></tr>"; } $out .= "</tbody>"; $out .= "</table>"; return $out; } } Usage: Install the module Create a new page under /admin/ Set the process for the new page to SimpleProcessModule If you have never created a module, just focus on the execute() method. Most of what is there is coded exactly as you might from a page template.
    1 point
  41. @Martijn, cool, i sent you my version with the changes, maybe you'll see a better way of doing some things than i did! the only thing that was bugging me about how i did it was that i had to have the 2 classes (both fa and fa-icon-name) in the config fields in the backend; perhaps there is a cleaner way of having the module code include the default class and only have the icon class in the module config screen fields; Also i put my css in the php/css file and not in the module - i changed the css so that the icons (color, size) match the new 2.4 theme icons. (to sum up for anyone else wondering why this module is useful in the 2.4 version, it allows you to specify icons for any page using the ID, otherwise all pages using a certain template would have the same icon; also it simplifies specifying icons for a lot of pages and templates at once and then using the css/php file in the templates directory you can change specific icons css.)
    1 point
  42. I've put together a Process module skeleton that may be good as a starting point for any Process module. It is well commented and fully functional as a demonstration. It also includes instructions on what to do with it when using it as a starting point for another module: http://modules.proce.../process-hello/ I'm planning to make more skeleton modules to cover all the bases.
    1 point
×
×
  • Create New...