Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/09/2018 in all areas

  1. Which Theme/Font is That? Tired of hearing that question when you share a screenshot or a tutorial on YouTube? Your problems are over! ? Introducing "Which Theme is That" Visual Studio Code extension. This extension will show on the status bar your workspace's current theme name and font. Install Grab it here: https://marketplace.visualstudio.com/items?itemName=sjardim.whichthemeisthat How to Run Install the extension and run the Command Palette Ctrl+Shift+P or Cmd+Shift+P on Mac. Search for "Which Theme is That?" and hit Enter. Screenshot Enjoy!
    4 points
  2. I think you are mixing ProcessModules with Other modules. The class skeleton of a process module has to look like this: class ProcessGoodNews extends Process implements Module { ... First add the prefix "Process" to your modules classname and also to the filename, and second you have to extend Process and not WireData. PS: the title can stay as is, Good News, or GoodNews, but the class name and filename should be prefixed with Process. PPS: I think you also have to prefix the execute() function name by three underscores: ___execute() < Thats wrong, as @teppo mentioned below. Sorry. PPPS: maybe some interesting reads about ProcessModules and different possibilities: https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/ https://processwire.com/blog/posts/new-module-configuration-options/ https://processwire.com/talk/topic/13618-does-using-dedicated-module-files-help-a-lazy-programmer/
    3 points
  3. The RC1 version for our next master release is here. This post covers all the details and information about how you can help. We also look at a a new PageAction module added to ListerPro, and a couple of other new modules currently in development: https://processwire.com/blog/posts/processwire-3.0.121-core-updates-and-more/
    2 points
  4. That isn't actually necessary; Process module execute methods don't have to be hookable. (Gadgetto, in case you haven't yet looked into the hook system, three underscores are only required if you want to make the function hookable – i.e. allow code in template files, modules, init.php / ready.php files within site directory, etc. to "hook" into their execution. Otherwise it's fine to leave them out.) On a loosely related note, you also don't have to set up your own PHP version comparison. You can define required PHP version with the "requires" setting ?
    2 points
  5. Also take a look at Ryan's helpful ProcessHello demo module: https://github.com/ryancramerdesign/ProcessHello It's a lot simpler to use getModuleInfo() (or its equivalent if using the other module configuration options Horst linked to above) to specify the page used by the Process module because then it will be automatically created on module install and removed on module uninstall. See the ProcessHello example: https://github.com/ryancramerdesign/ProcessHello/blob/9c1aa18eb40d069c7fb227f09badddc90f0b3276/ProcessHello.info.php#L41-L46
    2 points
  6. @Leftfield I am happy that you solved your problem ;). Maybe you can consider and few other options to get granularity or selection inside different types of featured posts (favorites). Option 1) Using Autocomplete page reference field Create and place Page Autocomplete field on some template (eg. on home or on some "widget" template). As example, if field "featured" is on Home page: $fav = $homepage->featured->eq(0); // or $homepage->featured->first $favs = $homepage->featured->slice(1); // skip first and get others $cards = $pages->find("template=blog-post, id!={$homepage->featured}"); Option 2) Get pages by priority levels Currently you are going with 3 check fields to get "sticky", "fav", and "favs". There is option how to get the same (checkboxes/radio) with only 1 field, but here I will try to describe (something different) how you can get "granularity" inside featured posts also using 1 field. Create integer field, and as example, set min to 0, and max to 3, and place it on your "blog-post" template. Later, in your code, it's very easy to get desired post by priority level. $fav = $pages->findOne('template=blog-post, priority=3, sort=-blog_date'); $favs = $pages->find('template=blog-post, priority=2, limit=2, sort=-blog_date'); // etc... $all_others = $pages->find('template=blog-post, priority<1, sort=-blog_date'); With this you can "describe the importance" of some post, and later, if it's needed, you can extend that with more levels without additional fields (changing only integer field range). Also with this option you can order posts by priority (sort=-priority). Option 3) Post priority levels with the addition of hooks (need to test) Here is option (for testing) to get on the website only 1 post with priority level 3, and later when someone add new page with the same level (3), previously post automatically would go to level 2, and so on. Here is working example using hooks, but please note that in some situation maybe could not works as expected. Before using this hook, you need to create "priority" field (option 2) and set your template inside hook part. Place this hook inside site/ready.php. // site/ready.php /* Before using this hook please create integer field "priority" and place it on desired template. */ $this->addHookAfter('Pages::saveReady', function(HookEvent $event){ $page = $event->arguments[0]; // if not desired template do nothing // note: set your own template if($page->template != 'blog-post')return; // priority level limit $limit = array( 1 => 3, // priority level 1, allowed max. 3 pages 2 => 2, // priority level 2, allowed max. 2 pages 3 => 1 // priority level 3, allowed max. 1 page ); // processing only if priority has changed and not changed to zero if($page->isChanged('priority') && $page->priority > 0) { $level = 3; // max priority level while($level > 0) { // test with different "sort" selector (eg. -modified, -created, or by custom date field) $group = $this->pages->find("template=blog-post, priority=$level, sort=-modified"); if($level == $page->priority) { $count = $group->has($page) ? $group->count : $group->count + 1; } else { $count = $group->has($page) ? $group->count - 1 : $group->count; } if($count >= $limit[$level]) { for($i = 1; $i <= ($count - $limit[$level]); $i++) { $group->eq($group->count - $i)->setAndSave('priority', $level - 1); } } $level = $level - 1; } } }); Regards.
    2 points
  7. 2 points
  8. Difficulties in this approach maybe, that there are many chained variations are possible in the wild. Also the intermediate variations in chains never will be served to browsers, but need to stay, as removing them will raise unnecessary recreations. Maybe for image heavy sites it can be useful to define all used variations in a collection of (some sort of) selector strings and execute this in a sandboxed scope against a default image name (basename.jpg). Using the resulting variation name patterns as whitelist, for example. Regardind file-a-time, this may be error prone by using any sort of hosting, crons or maintenance scripts running on a server or in a hosting account.
    2 points
  9. I'm really in love with FormBuilder, but the one thing missing to match all my end users' expectations were repeatable field groups. Think repeaters, in ProcessWire terms. Our primary application of PW is our corporate intranet, so "lines" of fields are quite common in the forms I build. We have all kinds of request forms where the information for a varying number of colleagues needs to be entered (from meal order to flight booking request) and where it is simply impractical to send a form for each, and I don't want to clutter my forms with multiple instances of fields that may only get used ten percent of the time. That's why I started to build FormBuilderMultiplier (link to GitHub). What it does: Adds an option to make a regular Fieldgroup repeatable Lets you limit the number of instances of a Fieldgroup on the form Adds an "Add row" button the form that adds another instance of the Fieldgroup's fields Adds a counter suffix at the end of every affected field's label Stores the entered values just like regular fields Makes the entered values available in preview and email notifications Supports most text based fields, textareas and selects (really, I haven't had enough time to test all the available choices yet) What it doesn't do (yet): Support saving to ProcessWire pages (i.e. real Repeaters) I haven't tested all the validation stuff, Date/Time inputs etc. yet, but since I'm utterly swamped with other stuff at work, I didn't want to wait until I have it polished. Any feedback is welcome. There might also be some issues with different output frameworks that I haven't encountered yet. The forms I work with mostly use UIKit. Status: Still alpha, so test well before using it in the field. Known issues: When rows are added, the form's iframe needs to be resized, which isn't completely clean yet. How it works: The Fieldgroup settings are added through regular hooks, as is the logic that adds the necessary field copies for processing the form and displaying previews. "Multiplied" field instances are suffixed with _NUM, where NUM is an incremental integer starting from 1. So if you have add two fields named "surname" and "givenname" to a fieldgroup and check the "multiply" checkbox, the form will initially have "surname_1" and "givenname_1" field (I'm still considering changing that to make the risk to shoot oneself into the foot by having a regular "surname_1" field somewhere else in the form less likely). When a "row" is added, the first row is cloned through JS and the counter in the fields' IDs, names and "for" attributes as well as the counter in the label are incremented before appending the copies to the Fieldset container in the form. To keep backend and frontend in sync, a hidden field named [name of the fieldset]__multiplier_rows is added to the form. Both the backend and the frontend script use this to store and retrieve the number of "rows". ToDo: Naturally, add the option to store the data in real repeaters when saving to pages. Do a lot of testing (and likely fixing). Make a few things (like the "Add row" button label etc.) configurable in field(set) context. Add a smooth API to retrieve the multiplied values as WireArrays. The mandatory moving screenshot:
    1 point
  10. Sorry to answer a question with another question, but is there a specific reason you want subscribers to be users? You mentioned being able to use the MODX permission system, but what do you use it for? While there's no technical reason why you couldn't make your subscribers ProcessWire users, the reason I'm asking is that unless there's a solid reason for it, I'd recommend not going that route. You'd essentially have to build an open registration system, where anyone can create new user accounts. While that isn't necessarily a problem in itself, coupled with any kind of permission related issue things could get very ugly very fast. That being said, depending on your needs you could use users, or you could create a custom template for your subscribers, or you could even create your own database table(s) – though that last option would likely not be preferable, considering that you wouldn't be able to benefit from ProcessWire's API. Whether you go with a custom template or choose to build upon built-in system users, I'd recommend looking into $pages->findMany(). Thousands of users / pages shouldn't be an issue.
    1 point
  11. @PWaddict I'll look into it.
    1 point
  12. Hi all, first post here but in case anyone else is experiencing this issue, I'd suggest checking if you are trying to use plain old http: instead of shiny yummy https: While taking my first test site out for its first spin in the wild I noticed this message, then immediately after visiting this post realized I hadn't yet enforced https on the site. As soon as I used https instead, the popups disappeared, and as soon as I switched back to http there they were again. Naturally can't say for sure what anyone else is experiencing, but it surely worked for me.
    1 point
  13. 1 point
  14. @Leftfield Welcome to the community. The easiest and most performant way is just to make page tree reflects your desirable URL structure. But often such structure looks messy. You can change it by using URL segments and rewriting page paths for your category and post templates. For example, for blogs, I use such a structure home/blog/ /authors /categories /cat1 /cat2 /posts /post1 /post2 I got such URLs site.com/blog/category/cat1 site.com/blog/posts/post1 etc. But I want to have such URLs and I want that every post can be listed in several categories, but for preventing contend duplication I want that it has only one accessible URL site.com/cat1/ site.com/cat1/post1/ site.com/cat2/post2/ To make it work you have to: 1. Enable URLs segments for your home page. 2. Create to Page Reference fields and add it to your post template blog_section - Page reference field ( Page field value type set to Single page, selector 'template=blog_category') - this one we will use for building URL for the current post. blog_categories - Page reference field ( Page field value type set to Multiple pages, selector 'template=blog_category') 2. In your ready.php $pages->addHookAfter('Page(template=blog-category)::path', function ($e) { $page = $e->object; $e->replace = true; $e->return = "/" . $page->name . "/"; }); $pages->addHookAfter('Page(template=post)::path', function ($e) { $page = $e->object; if ($page->blog_section) { $slug = $page->blog_section->name; } else { $slug = $page->parent('template=blog')->name; //fallback } $e->replace = true; $e->return = "/" . $slug . "/" . $page->name . "/"; }); 3. In your home.php if ($input->urlSegment3) throw new Wire404Exception(); if ($input->urlSegment2) { $post_name = $input->urlSegment2; $match = $pages->get($sanitizer->selectorValue($post_name)); if (!$match->id) throw new Wire404Exception(); echo $match->render(); return $this->halt(); } if ($input->urlSegment1) { $category_name = $input->urlSegment1; $match = $pages->get($sanitizer->selectorValue($category_name)); if (!$match->id) throw new Wire404Exception(); echo $match->render(); return $this->halt(); } It's not tested and there can be some errors, but I hope you get a general idea.
    1 point
  15. Without the new module, you would have to temporary modify your template files by adding the following param to the options array "forceNew" => true for every pageimage call that you wants to be affected.
    1 point
  16. @Ivan Gretsky thank you for helping!!! I really appreciate!!! Here's how I solved thanks to my friend @OLSA: $exclude = new PageArray(); $exclude->add($fav); $exclude->add($favs); $cards = $pages->find("template=blog-post, id!=$exclude, blog_post_sticky!=1, sort=-blog_date, limit={$blogSettings->blog_quantity}");
    1 point
  17. The PageActionClearImageVariations module sounds very useful, thanks @ryan. I have a number of sites where I suspect I have a significant amount of wasted disk space due to orphaned image variations. Trouble is that I don't think I would able to identify the orphaned variations from attributes such as width and height. What would be ideal would be if there was some way to identify orphaned variations based on whether they are called within any site code (template files or modules). Do you think there would be any way to accomplish that? Another idea I had was to see if fileatime() could be used to check if a file has not been accessed in a long time (which would be configurable) but based on a quick test it seems that the last accessed time does not get updated when an image is loaded by a browser. Any other approaches that could be useful here?
    1 point
  18. Depending on how complex your needs are, the core does offer some support. Use something like this for the selector value for a page field: parent=page.otherpagefield That allows for ajax population of one select based on the selected value of the otherpagefield
    1 point
×
×
  • Create New...