Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/26/2014 in all areas

  1. 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.
    6 points
  2. That line is checking to see what iteration of the loop you are in. $i is set to 1 before the start of the foreach loop. At the end of each loop, 1 is added to the current value of $i with the $i++; line. So by getting the number of children of the page and setting $colcount to that value and then checking whether $i is equal to the number of required columns you are checking whether to add the "end" class or not. Hope that makes sense.
    3 points
  3. This will do what you are looking for. You need to get the page array for the page you are adding: $pageitem and also use "add" to add it to the array of pages held by the page field. $p = $pages->get(1234); $pageitem = $pages->get(4321); $p->of(false); $p->foo->add($pageitem); $p->save(); Hope that makes sense.
    3 points
  4. Just add parent::init() to the init function. Then you don't need parent::install() and parent::uninstall() (I started updating my process modules with this new technique )
    2 points
  5. Hey, I will be at the 31c3 this week (starting at the 27th) in Hamburg. Is anybody else of you ProcessWire guys going to be there (and maybe would like to meet )? Let me know! Greets, Nico
    2 points
  6. С рождеством! Merry Christmass! In Russia we celebrate it only on 7th of january as orthodox church still uses Julian calendar. But it is just a nice way to celebrate twice))
    2 points
  7. Build my first PW website...., and not my last. Like PW a lot. It is fun to work with and sometimes a challenge. Spent, more than once, some ours fiddling on code issues, but real proud when I got it to work. Could not have done it without the feedback of the members from this community, thank you! Modules I used: -Email Obfuscation -Form Builder -SEO -Blog -Google Analytics -Protected Mode -Wire Mail SMTP Other: -Bootstrap -Animate -WOW -Unslider Website: http://www.tweemansterk.nl
    1 point
  8. Adrian, You are indeed a miracle worker and a very talented developer. Thanks for updating this module! The new changes are immediately useful and I owe you a depth of gratitude. Best Regards, Charles
    1 point
  9. these are the postings where i am happy using pocketgrid. the resulting code for your template is quite simple, even though you have to define some css rules first, but you don't have to take care of inserting </div><div class="row"> every 3rd item and doing modulo %3 == 0 and $i++ things and all that and keep your template really clear! <div class="block-group"> <?php foreach ($page->locations as $loc) { ?> <div class="col3 block"> <h3><?= $loc->title ?></h3> <p><?= nl2br($loc->adresse) ?></p> <p><small><a href="<?= $loc->website ?>" target="_blank"><?= $loc->website ?></a></small></p> </div> <?php } ?> </div> you can define custom breakpoints for your class "col3" (eg. 3 cols from 1000px+, 2 cols from 500px+ and 1 col below 500px screen resolution) and it already takes care of correct floating: http://arnaudleray.github.io/pocketgrid/docs/#automatic-rows-in-real-life it seems that your mentioned block grid approach is quite similar - so i'm kind of happy reading about that
    1 point
  10. Hi again - I have just committed an update to my fork that supports capturing the received date and the from address (actually I parsed out the name associated with the email address). Is that what you are looking for, or do you actually want the email address? If so, I might need to add an option to choose what is required. Anyway, let me know if things work for you.
    1 point
  11. Just for fun, I decided to try saving from copy-pasted CSV data using MySQL LOAD DATA INFILE. Now this MySQL feature is something you use for really serious transactions. Testing with 'only' 1000 values seems an overkill. Anyway, here's the results: Testing with same data as in my post above (10X100 table with 1000 values) Method 1: CSV + MySQL LOAD DATA INFILE 1. Copy-pasted CSV values in the format: Name|Age|Country|Bank Account|Phone|Credit Card|Email|Salary|Address|Post Code Quinlan T. Romero|36|Burkina Faso|RS31212461883550021066|(989) 462-3421|863|Integer.vulputate@Curabiturut.ca|£066.39|P.O. Box 161, 2347 Donec Street|6518 2. Flip the CSV values to match our db structure, i.e.: data(matrix_row) | matrix_column | matrix_value - explode csv line by line - str_getcsv csv line to create array of the csv line - push sanitised csv values into a new CSV array mirroring our 'db structure' (i.e. including row and column page->id) - we do this because our raw csv data is in matrix table format and LOAD DATA INFILE won't read it correctly array( [0] => ( [0] => row->id [1] => column->id [2] => value ) ) 3. Write CSV values to a data.csv file - fopen a data.csv in this page's /assets/files. Force create the file w+ if one doesn't exist - fputcsv the CSV array line by line 4. LOAD DATA INFILE - instantiate a new PW (PDO) $this->wire('database'); - Delete this page's existing values from db - Execute a LOAD DATA INFILE, reading through our data.csv and writing to db (at high speed ) - Delete data.csv Method 2: CSV + 'Saving Normally' 1. Similar to above but we don't write to a data.csv nor use LOAD DATA INFILE 2. Prepare csv array using str_getcsv similar to above...but 3. Our CSV array is slightly different (but timings don't matter because of the different structure) [row->id] => ( [column->id] => value ) Results: Memory usage and Timings Normal LOAD DATA INFILE processCSV() mem_end 15,105,984 13,767,352 mem_start 12,754,968 12,761,496 Diff 2,351,016 1,005,856 time 0.1240 0.0740 ___processInput() mem_end 14,974,128 13,328,584 mem_start 12,754,128 12,760,504 Diff 2,220,000 568,080 time 0.1240 0.0940 ___sleepValue() mem_end 15,504,760 Not Applicable mem_start 15,122,112 Diff 382,648 time 0.0160 Not Applicable As you can see LOAD DATA INFILE is the (clear?) winner. Not sure if LOAD DATA INFILE is enabled everywhere though? Anyway, for now, not sure if this is the route I should take. Besides, I got something else planned (in my head!) for handling really large grid tables.. Before you ask, no we are NOT using LOAD DATA INFILE with the LOCAL option (security concerns with that option!)
    1 point
  12. This should work... <?php $columns = $page->children; $colcount = $columns->count(); $i = 1; echo '<div class="row">'; foreach ($columns as $column) { if($i == $colcount){ echo "<div class='medium-4 columns end'> <a href='{$column->url}'>$column->title</a>"; } else { echo "<div class='medium-4 columns'> <a href='{$column->url}'>$column->title</a>"; }; if($i % 3 == 0) {echo '</div></div><div class="row">';} else {echo '</div>';} $i++; } echo '</div>'; ?> I have some very similar code to yours in a site currently under development, even including a slight variation on the modulo magic, but I was lazy and applied the 'end' class to every column.
    1 point
  13. Nico, sure - no reason to work with others. Process modules are what admin pages use.
    1 point
  14. Yes that was Stollen. And, ähm, this was you? I thought it was the angel.
    1 point
  15. Not sad at all. A whiz in the accoustics and video department though
    1 point
  16. This only works for Process-Modules, doesn't it?
    1 point
  17. Ah! My bad - didn't move parent::___uninstall() over when I started again... lol
    1 point
  18. @Nico - there is an easier way. One can now define the pages in the info, which can also be in a JSON file: "page": { "name": "the-name", "parent": "setup", "title": "The Title" }, So I know I can manually uninstall the page - but it should do this automatically. Haven't checked out the source though...
    1 point
  19. Was that Stollen? (See what I did there?)
    1 point
  20. I updated the module page, thanks for the heads up Ivan!
    1 point
×
×
  • Create New...