Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 09/17/2019 in all areas

  1. Modules Manager 2 provides an easy to use interface to download, update, install, uninstall and configure modules. It is meant to provide an optimized alternative to the core ProcessModule dashboard. Maybe @ryan agrees to merge it to the core at some point when it is finished and polished. Features: Seamlessly download, update, install, uninstall or delete modules Live-Search (aka find as you type) for module names Live-Search (aka find as you type) for categories Browse new and unkown modules from the modules directory on modules.processwire.com Choose your favorite layout (cards, reduced cards, table) Modern UIKit design (therefore only works with AdminThemeUikit) Caches the module list from modules.processwire.com directory locally. What is Modules Manager 2? Why a new module manager? Some people including myself think that the actual module installation in ProcessWire could be improved in some places. Make it easy for ProcessWire beginners and power users Offer better discoverbility to find the right module Make it easier and faster for powerusers to manage modules A manager that list all official modules is a feature, that many other frameworks/CMS's like ModX, WordPress or PrestaShop have by default. What are the disadvantages of the actual core module interface? Installation of a module is not very user-friendly: You have to be aware where to get new modules, search for a module, copy or remember the module name or URL, go back to your ProcessWire installation, paste the module name(URL, click on "get module info" and finally install the module It only displays installed modules, not the ones that are available in the modules directory Uninstalling a module requires you to go to the module detail page, click a checkbox and then submit the change. After that you have to go back to the module overview page. It only displays installed modules, not the ones that are available in the modules directory, so it makes discovering modules hard BETA software Use this module at your own risk. I am not responsible for any damage or unexpected behaviour. Some things might not work fully, please see the TODO list for details. I need your feedback and help This module is still in development and I am happy to discuss with you and get some feedback. What do you like? What is missing? What could make the process even easier? Ask, suggest or provide pull requests. You can download the module at https://modules.processwire.com/modules/modules-manager2/ or from Github: https://github.com/jmartsch/processwire-modules-manager2
    18 points
  2. I'm pretty sure I've seen something similar happen when nesting an <a></a> inside another <a></a> - looks "fine" in page source but the browser attempts to escape them or something and it displays differently in the inspector. Steps I would go through is to to replace each var value with a blank string, go through each methodically, or maybe remove each <a></a> and add each one back in to identify which one is triggering it. You might find it completely unrelated to the above, but it'll get you closer to the source of the issue! PS - Grammarly browser extension and CKEditor 4 don't mix well. Had to ask a number of clients and colleagues to disable it so they can actually save content.
    3 points
  3. Teppo, I'm writing my first message on this forum (hi!) to thank you for this module. I'm testing it on a small local test site at the moment, and really liking it so far!
    3 points
  4. @Leftfield I think that URL segmetns is the way to go. wire()->addHook("Page(template=product)::path", function($e) { $page = $e->object; $e->return = "/{$page->name}/pr/{$page->hash_field}/"; }); Then you have to enable URL segments for your home template. And in template file if (input()->urlSegment(1)) { $pagename = input()->urlSegment(1); $hash = $input()->urlSegment(3); $match = pages()->findOne("template=product, name={$pagename}, hash_field={$hash}"); if (!$match->id) throw new Wire404Exception(); echo $match->render(); return $this->halt(); }
    3 points
  5. Ok my feedback is mainly just UX/UI 1. I love the cards layout and how much info is presented. It's informative without being crowded. I think a list view is also needed too and a user should be able to flick between two. Particularly when viewing modules with an update, I want to quickly scan down a compact list and see what might require an update. 2. On the filters for 'Show only installed', 'Show only uninstalled', 'Show only updateable, 'Show most recommended', 'Picked', I wonder if these could be a little more compact and less wordy. IE a simple dropdown with a title of Display and then 4 shorter options of Installed Uninstalled Updatable Most recommended Picked Happy to do a quick mockup/wireframe if that's any use to you. 3. Will 'Show only uninstalled' display modules I have installed and subsequently uninstalled or display everything that's not installed? Might be a better label for this?
    2 points
  6. Since this thread was started a hasPage property has been added to Inputfield instances in PW. So you can do this: $wire->addHookBefore('Inputfield::render', function(HookEvent $event) { /* @var Inputfield $inputfield */ $inputfield = $event->object; $page = $inputfield->hasPage; if($page) { // Use $page bd($page->name, 'page name'); } });
    2 points
  7. I just wanted to mention. I found a new job as a front-end dev at https://backslash.ch. Since 2 months there already and enjoy it. We work with in-house CMS specially targeted to governments. So a lot less PW for me in the future, but I'll use it as my tool for private projects.
    2 points
  8. Hi @MateThemes, Unfortunately there will be a bit of a delay due to some unforeseen circumstances. It could be winter before we see the first release.
    1 point
  9. New Release 0.6.2 – Codename »boring« Fixed Login screen design ? Readme ? AOS Language Switch overlapping notifications ? --- Get Release Notifications ProcessWire Modules Repository Gitlab & Issues
    1 point
  10. There are some threads with similar topics discussing your need. You may find some ideas on how to achieve it. But just for me to understand this better... why do you want/need such a weird URL? That doesn't make sense - generally speaking.
    1 point
  11. You can check whether page rendered in admin if so, do nothing. if (strpos($_SERVER['REQUEST_URI'], $this->wire('config')->urls->admin) === 0 || $this->wire('page')->template->name == 'admin') return;
    1 point
  12. 1 point
  13. Hey folks! I've been a bit quiet here about Wireframe, but the thing is that I've finally got a couple of "real sites" (as in not my own projects) to implement it on, and that has brought up some new requirements and a few issues. I haven't had the time to dig into a whole lot of really new stuff (components and such), but I have made a lot of other updates to the framework. As such, Wireframe 0.6 was released late yesterday. (A release on Friday the 13th, consisting of a total of 13 commits – not being superstitious here.) I've been updating the docs at wireframe-framework.com as well, but some parts remain a bit outdated. A lot of what happened in this version doesn't really affect the use of Wireframe, but some things do – and one change may even break some existing implementations: It used to be possible to set the view file or layout from Controller with $this->view->layout = "some-layout" or $this->view->view = "json". This has been deprecated and removed in favour of a setter/getter API: $this->view->setLayout("some-layout") and $this->view->setView("json"), and getLayout() / getView() for reading the value. In addition to some obvious benefits from type hinting etc. this also makes it harder to accidentally change something when you thought you were just passing a variable to the View ? There are now three ways to perform actions and pass data from a Controller to the View: Controller::init() (triggered as soon as the Controller class is loaded), public methods (which are made accessible in the View as $this->method_name), and a new addition Controller::render() (called right before the page is rendered). In most cases where one might've used the init() method before, render() is a better choice, as there's less chance that code will get executed "unnecessarily". In addition to existing Page::layout() and Page::view() methods there are now specific setters/getters: Page::setLayout("layout-name"), Page::getLayout(), etc. Original "unified setter+getter" methods may actually get removed at some point, as they're often ambiguous and make code arguably less readable. Quite a few other changes as well, some of which improve performance and others that make the API more polished. Some bug fixes too, though those mostly apply to what I'd consider "border cases" ? Here's the full changelog for Wireframe 0.6.0: ### Added - New Page methods Page::getLayout(), Page::setLayout(), Page::getView(), and Page::setView(). - New Controller::render() method, executed right before a page is actually rendered. - New ViewData class for storing (internal) data required by the View class. - New getter/setter methods for ViewData properties for the View class. - New method Wireframe::getConfig() for getting current config settings. - New method ViewPlaceholders::has() for checking if a placeholder has already been populated. ### Changed - Various View-related features moved from Wireframe module and ViewPlaceholders class to the View class. - Removed access to local get* and set* methods via the PHP's magic setter method __set() and getter method __get() in the View class. - Redirect feature no longer fails if provided with a WireArray data type; in these cases the first item is used as the redirect target. - Improvements to PHPDoc comments. ### Fixed - An issue with Config class where the "all directories exist" message was sometimes displayed unintentionally. - An issue where View Placeholder values might've been overwritten because existence of earlier value was checked inproperly. - An issue where empty / null view file would be automatically replaced with value "default". On a related note, for this version I decided to give sonarcloud a try. For those who don't know it, it's a sort of a code quality inspector, and it's free for public projects. It didn't have a whole lot to complain about at this point, but it's good to have some sort of validation in place just in case. I will also be digging deeper into reported "code smells", as some of them definitely make sense to me ?
    1 point
  14. As threatened in Ryan's announcement for 3.0.139, I built a little module for sliding toggles as a replacement for checkboxes. Styling of the input is CSS3 only (with all the usual caveats about older browsers), no JS necessary, and may still be a bit "rough around the edges", so to speak, since I didn't have much time for testing on different devices or brushing things up enough so I'd feel comfortable pushing it to the module directory. But here's the link to the GitHub repo for now: InputfieldSlideToggle Fieldtype and Inputfield that implements smartphone-style toggles as replacement for checkbox inputs. The visualization is CSS-only, no additional JS necessary. Status Beta, use with caution Features / Field Settings Size You can render the toggles in four different sizes: small, medium, large and extra large. Off Color Currently, "unchecked" toggles can be displayed either in grey (default) or red. On Color "Checked" toggles can be rendered in one of these colors: blue (default), black, green, grey, orange or red. Screenshots Some examples with checkbox label View all Size and Color Combinations Small toggles Medium toggles Big toggles Extra big toggles
    1 point
  15. Hey folks – a quick update: Wireframe 0.5.0 was released couple of days ago. Compared to 0.4.x this version mainly fixes bugs and improves performance – nothing particularly major, but if you're using Wireframe, it's a recommended update. On a loosely related note, Tracy Debugger has been really helpful in figuring things out, identifying bottlenecks, etc. Brilliant module ?
    1 point
  16. Well that's propably why, since I have 3.0.123! Thanks @dragan, sometimes the simplest things to check just don't come to mind ?
    1 point
  17. @iipa You probably have to update PW. It was introduced with 3.0.127: https://processwire.com/blog/posts/pw-3.0.127/
    1 point
  18. Pinging the grid heads: @bernhard @jmartsch @mel47 @dragan @szabesz In short, I have modified RockGrid to work with Tabulator instead of ag-Grid. I left out ajax and plugins for now. I fully understand, if Bernhard is not interested in switching the "engine" of RockGrid, but at least it is food for thought and a proven alternate solution ? The "HackGrid" can be found here: https://github.com/mestaritonttu/FieldtypeRockGrid/tree/tabulator Longer story: During the last week of November I ran into Tabulator by accident. It occurred to me "someone in the early days of RockGrid suggested some other solution". I searched the PW forums and found out that someone was szabesz and the solution was Tabulator! Now, the important thing here is that since the PW forum discussion (April 2018), Tabulator has seen significant changes. It got rid of jQuery & jQuery UI dependencies and added a ton of features. Why have I decided to switch to Tabulator? Lately ag-Grid has left a bad taste in my mouth - the performance of its row autoheight sucks, so I had to work around it - inside the autoheight workaround I had to add another workaround to avoid an infinite event triggering/listening loop - the closed nature is showing its bad sides more and more, like not being able to see the content in their enterprise bug tracker So what do we get with Tabulator? - row autoheight that just works - dropdown filter out of the box, so I don't need my awkward external filter - features matching the enterprise version of ag-Grid, such as http://tabulator.info/docs/4.1/select#setup-range http://tabulator.info/docs/4.1/group http://tabulator.info/docs/4.1/download#xlsx http://tabulator.info/docs/4.1/tree http://tabulator.info/examples/4.1#nested-tables http://tabulator.info/docs/4.1/clipboard What are the philosophical differences? In the words of the Tabulator main dev, ag-Grid focuses on being a fully functional spreadsheet while Tabulator goes more down the route of interactive table. I would have announced this already nearly 3 weeks ago, but caught pneumonia ? Use on the RockGrid side is really not much different. Mostly just using col.title instead of col.headerName. For some reason the grid.js stuff is lost (to get the field titles), but I did not have time to investigate.
    1 point
  19. I've found this module really useful, and thought I'd share an interesting use case I've come up with for it. I had a client who wanted both the functionality of pageTable, and PageTableExtended, ie they wanted a tabular summary like PageTable provides, but with the option to expand or collapse to display rendered detail from a template like PageTableExtended allows. It turns out, I was able to provide the desired functionality using PageTableExtended, and built in UI-kit classes in the template file I provided to PageTableExtended. <!-- This is the summary section, like displayed by PageTable --> <table class="AdminDataTable AdminDataList uk-table uk-table-divider uk-table-justify uk-table-small"> <thead> <tr> <th>BOM</th> <th>Cases to produce</th> <th>+/- or exact</th> <th>Notes</th> </tr> </thead> <tr> <td><?= $bom->title ?></td> <td><?= $page->cases ?></td> <td><?= $page->exact ?></td> <td><?= $page->notes ?></td> </tr> </table> <!-- Toggle to display detail section --> <a herf="#" class="toggleRenderedLayout"> <i class="toggle-icon fa fa-angle-right"></i> </a> <span class="renderedLayoutTitle">BOM Details</span> <!-- Detail section, hidden by default, using built in ui-kit css. --> <div class="renderedLayout hiddenOnStart"> <div uk-grid uk-margin-small-top> <div class="uk-width-1-3 uk-margin-small-top"><strong>Wine Variety </strong><?= $bom->wineVariety->title ?></div> <div class="uk-width-1-3 uk-margin-small-top"><strong>Brand </strong><?= $bom->brand->title ?></div> <div class="uk-width-1-3 uk-margin-small-top"><strong>Market </strong><?= $bom->market->title ?></div> <div class="uk-width-1-1 uk-margin-small-top"><strong>Orientation </strong><?= $bom->orienation->title ?></div> ... </div> </div> Screenshot, showing the tabular summary, with the detail section expanded.
    1 point
  20. [quotamos]This is really interesting stuff and I'm learning so much from it. I've already tested Soma's code and it works very well. Is there a way of configuring $form->render() so that it outputs different html (divs for ul/li etc.)? [/quotamos] you.can usage. $form->setMarkup(); und $form->setClasses(); two.set markups und html caresses. see.eliamos /wire/core/InputfieldWrapper.php
    1 point
×
×
  • Create New...