Jump to content

Leaderboard

Popular Content

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

  1. @Markus (Blue Tomato) the showIf only works with fields and there values. AFAIK, the published / unpublished value cannot be used as condition for showIf directly in the template editor. But you may define a hook and set the visibility of that field within the hook. Here is example code as a starting point. You can use this in site/ready.php $wire->addHookAfter('ProcessPageEdit::buildForm', function (HookEvent $event) { // make sure we're editing a page and not a user if($event->process != 'ProcessPageEdit') return; // get page and form $page = $event->object->getPage(); $form = $event->return; // optionally check for matching template(s) with a condition if('mydesiredtemplatename' != $page->template->name) return; // get the field and conditionally set the visibility $form->get('yourfieldname')->collapsed = $page->isUnpublished() ? Inputfield::collapsedHidden : Inputfield::collapsedNo; $event->return = $form; return; }
    3 points
  2. Hey @Mike Rockett, Any chance you could add this module to Packagist? Would love to use it on my current project, but I'm relying on Composer. Would be nice not to have to install this module via Git or add the repository manually to composer.json. It would also be awesome if you could declare type as pw-module and add wireframe-framework/processwire-composer-installer as a dependency for easy installing. Thanks for considering! ??
    3 points
  3. Hey folks! I'm happy to finally introduce a project I've been working on for quite a while now: it's called Wireframe, and it is an output framework for ProcessWire. Note that I'm posting this in the module development area, maily because this project is still in rather early stage. I've built a couple of sites with it myself, and parts of the codebase have been powering some pretty big and complex sites for many years now, but this should still be considered a soft launch ? -- Long story short, Wireframe is a module that provides the "backbone" for building sites (and apps) with ProcessWire using an MVC (or perhaps MVVM... one of those three or four letter acronyms anyway) inspired methodology. You could say that it's an output strategy, but I prefer the term "output framework", since in my mind the word "strategy" means something less tangible. A way of doing things, rather than a tool that actually does things. Wireframe (the module) provides a basic implementation for some familiar MVC concepts, such as Controllers and a View layer – the latter of which consists of layouts, partials, and template-specific views. There's no "model" layer, since in this context ProcessWire is the model. As a module Wireframe is actually quite simple – not even nearly the biggest one I've built – but there's still quite a bit of stuff to "get", so I've put together a demo & documentation site for it at https://wireframe-framework.com/. In addition to the core module, I'm also working on a couple of site profiles based on it. My current idea is actually to keep the module very light-weight, and implement most of the "opinionated" stuff in site profiles and/or companion modules. For an example MarkupMenu (which I released a while ago) was developed as one of those "companion modules" when I needed a menu module to use on the site profiles. Currently there are two public site profiles based on Wireframe: site-wireframe-docs is the demo&docs site mentioned above, just with placeholder content replaced with placeholder content. It's not a particularly complex site, but I believe it's still a pretty nice way to dig into the Wireframe module. site-wireframe-boilerplate is a boilerplate (or starter) site profile based on the docs site. This is still very much a work in progress, but essentially I'm trying to build a flexible yet full-featured starter profile you can just grab and start building upon. There will be a proper build process for resources, it will include most of the basic features one tends to need from site to site, etc. -- Requirements and getting started: Wireframe can be installed just like any ProcessWire module. Just clone or download it to your site/modules/ directory and install. It doesn't, though, do a whole lot of stuff on itself – please check out the documentation site for a step-by-step guide on setting up the directory structure, adding the "bootstrap file", etc. You may find it easier to install one of the site profiles mentioned above, but note that this process involves the use of Composer. In the case of the site profiles you can install ProcessWire as usual and download or clone the site profile directory into your setup, but after that you should run "composer install" to get all the dependencies – including the Wireframe module – in place. Hard requirements for Wireframe are ProcessWire 3.0.112 and PHP 7.1+. The codebase is authored with current PHP versions in mind, and while running it on 7.0 may be possible, anything below that definitely won't work. A feature I added just today to the Wireframe module is that in case ProcessWire has write access to your site/templates/ directory, you can use the module settings screen to create the expected directories automatically. Currently that's all, and the module won't – for an example – create Controllers or layouts for you, so you should check out the site profiles for examples on these. (I'm probably going to include some additional helper features in the near future.) -- This project is loosely based on an earlier project called pw-mvc, i.e. the main concepts (such as Controllers and the View layer) are very similar. That being said, Wireframe is a major upgrade in terms of both functionality and architecture: namespaces and autoloader support are now baked in, the codebase requires PHP 7, Controllers are classes extending \Wireframe\Controller (instead of regular "flat" PHP files), implementation based on a module instead of a collection of drop-in files, etc. While Wireframe is indeed still in a relatively early stage (0.3.0 was launched today, in case version numbers matter) for the most part I'm happy with the way it works, and likely won't change it too drastically anytime soon – so feel free to give it a try, and if you do, please let me know how it went. I will continue building upon this project, and I am also constantly working on various side projects, such as the site profiles and a few unannounced helper modules. I should probably add that while Wireframe is not hard to use, it is more geared towards those interested in "software development" type methodology. With future updates to the module, the site profiles, and the docs I hope to lower the learning curve, but certain level of "developer focus" will remain. Although of course the optimal outcome would be if I could use this project to lure more folks towards that end of the spectrum... ? -- Please let me know what you think – and thanks in advance!
    2 points
  4. On a sidenote: You can also disable caching while Chrome inspector is open inside the settings: (of course, if you're testing with several other browsers plus mobile devices at the same time, the query-string approach is better)
    2 points
  5. I believe that is because repeaters store their pages under a different section in the admin tree(Admin>Repeaters>name_of_repeater) which isn't publicly accessible to guests. I think you have to add check_access=0 to your find selector? See https://processwire.com/docs/selectors/#access_control Hope that helps
    2 points
  6. I wouldn't do a 302 for the operation. This essentially doubles the amount of requests the browser needs to do for images and I'm not even sure if it would actually cache-bust anything. Rather rewrite the url only internally so apache serves the correct file under the incoming url with cache-busting.
    2 points
  7. We had the opportunity and pleasure to create a multi-site with ProcessWire. The Walter Group consists of four investment units, each with its own domain name(s). Thus, six domain names with two different language negotiation strategies had to be managed by a single installation. The four sites more or less share news, staff and other information. waltergroup.ca (in English) and groupewalter.ca (in French) walterfinancial.ca (in English) and financierewalter.ca (in French) waltercapital.ca/en and /fr walter-gam.com/en and /fr The Multisite module was designed to meet the challenge. A tree structure has been created with the four units, with news and management staff pages placed outside these sites so that they can be more easily managed by Walter Group. We also used FormBuilder for the four contact forms whose entries had to be directed to different people. The result really pleased the Walter group, long used to complicated CMS!
    2 points
  8. Thanks, Ivan! ? I haven't figured out the details yet, but at some point I'm going to look into adding templating language support. For the time being all options are open, so don't really have anything else to share at this point than "I will look into it eventually". 1. Currently partials are intended as simple drop-in (include) files with very little logic. I do have some ideas in my backlog that come pretty close to this topic, but I'll have to give them a bit more thought before implementing. Wouldn't want to put something in now, and then regret it right away... ? I've often preferred render functions, i.e. functions that generate markup, in case I need to bake some logic into smaller bits and pieces of the site. A "RenderUtils" class with multiple render methods would be one solution, and of course you can already use ProcessWire's own features to render a partial: $page->renderValue(), $files->render(), TemplateFile::render(), etc. In the long term perhaps we could add some kind of a helper class to the framework for handling these situations – just not quite sure yet how to approach this. If you could give me an example or two of what sort of situations you tend to run into, I'd be grateful – would be good to know that I'm actually solving the right problem ? 2. Not Wireframe specifically, but I did build a few rather large sites with pw-mvc and RepeaterMatrix. In those cases I ended up using field templates (/site/templates/fields/) for the bulk of the RepeaterMatrix stuff. Worked quite nicely, really. I'll add a note to write a bit about this to the "Patterns and practices" page.
    1 point
  9. It really depends how your utilizing pages. For example: <?php header("Content-type: text/xml"); $people = $pages->find('template=person'); // or whatever your template is $out = "<?xml version = \"1.0\"?>"; $out .= "<contact-info>"; foreach($people as $person) { $out .= "<name>" . person->title . "</name>"; // whatever field is storing the info $out .= "<company>" . person->company . "</company>"; // whatever field is storing the info $out .= "<phone>" . person->phone . "</phone>"; // whatever field is storing the info } $out .= "</contact-info>"; echo $out; ?> The above would find all "people" and output them in contact info (well, everyone's info would be place inside the contact info tags). You could just move those tags inside the foreach loop if you needed each tag to have their own. Alternatively, you could use $pages->get() method to get a certain page (person. A little bit more information regarding your template structure could help us better give advice/pointers.
    1 point
  10. Two more) How is it possible to separate logic for partials from their presentation? I often find the need to prepare content for partials same way as for the views. Do you have experience of using Wireframe with RepeaterMatrix based content?
    1 point
  11. This time you came prepared, @teppo! Great intro post and a cool documentation site. Congratulations! I did not have time to dig into it (yet). The 1st question that comes to mind is can twig or some other templating language be plugged in for the views?
    1 point
  12. Good evening here) Maybe this feature can help you to manage users with lots of custom fields. The frontend login should be managed with some custom code or a ready-made module like this one.
    1 point
  13. You could use a simple PHP script that serves the image with readfile() and set appropriate headers in that script. Maybe setup a dummy PW page with URL-segments enabled (or use a plain old query string) that will act as a "gateway" to those images. If you don't need to have the exact same filename on each request (download), then you you could even create the filename dynamically each time with adding / injecting time() or microtime() to the filename PHP will create for you: header('Content-Disposition: attachment; filename="'.basename($file).'"');
    1 point
  14. @Pixrael Thanks, that makes perfect sense. Are you sure the query parameter doesn't work? It really should, since it's a different request and may return different results for some services. Maybe Chrome is employing some heuristics to determine that it's always the same image ... though it isn't in your case ... I don't know, sounds curious. In any case, your HTTP-header method is probably the best approach for this scenario! Though you really only need the Cache-Control header; Expires, ETag and and Pragma are superfluous except for the most legacy of legacy browsers ? @dragan Firefox Developer Edition master race! ? Though I don't always have the Developer Tools open while writing my templates, and as you said I frequently need to test on other devices, so I prefer the caching busting approach. I usually have a $config->theme_version parameter in my config that gets appended to each CSS / JS URL, this way I can also easily invalidate caches on live sites when I push an update. During development (coupled to $config->debug) I just append the current timestamp, so the parameter changes for each request.
    1 point
  15. @MoritzLost Thanks for your comments. The first thing I tried was this ?v=XXXX technique, but do not works 100%, at least in chrome (several days testing that) not always reload the file. I don't know why, maybe chrome use more aggressive approach to save bandwidth or for speed.. "why force it to load it again?" .. because this is a tool that generate a picture to download, the customer can modify the tool paramaters and regenerate the picture again infinitely.. I don't want to create new pictures each time the user click the generate button (to save disk space at server), my approach is to create only one picture per user session, and use the token value as file name, so the tool overwrite it each time the picture is regenerate. I use ajax for that and with the response I change the src attribute in an image element to display the result.. this is the reason why I need that image must be forced to download each time when I change the src attribute.. Oh, this description looks a little complicated.. I explain correctly?
    1 point
  16. @Pixrael A simpler approach that doesn't require any server-side adjustments at all would be to include the cache-busting parameter as a query variable instead. For example: /site/downloads/9VefFf6vstUR0q1ywzPgjXw4PfAgYqGp.png?v=1562618833 I use something like this during development for my CSS / JS assets, so the browser downloads those anew for each request and I see all changes immediately ... The browser will not use the cached image if the query string differs. This way you don't need to rewrite any URLs in Apache. I would also strongly advise not to go with the second approach (using HTTP-headers to disable caching), as this way the images can never be cached and reused, which means your site takes a major performance hit. Can I ask why you need to do this at all? If the browser has already loaded the image, why force it to load it again?
    1 point
  17. Sorry, no. The current text watermark method analyzes the images and decides between white, gray and black in a automated way. The reason behind that is, you can apply text to any images without knowing which colors it includes.
    1 point
  18. To test the explode() method you would dump its return value (an array):
    1 point
  19. Yeah, pretty much. It's not as clean as I would like it, but it works fine. I discovered that it works fine if I include the necessary javascript in the $config->ajax part of my page, then it works as expected: if ($config->ajax) { $scf = $modules->get('SimpleContactForm'); echo "<div>{$scf->render()}</div>"; // if not enclosed in a div, my column formatting was getting lost echo "<script src=\"{$config->urls->siteModules}SimpleContactForm/resources/jquery.simplecontactform.js\"></script>"; echo "<script src=\"{$config->urls->templates}js/main.js\"></script>"; // including the 2 scripts made it work. } else { ... // full page with contact form The only downside is that every time the form submitted with missing required fields (i.e., to throw an error), the 2 script includes get added to the form section. This makes for redundant/duplicate scripts called. Not ideal, but it works. If anyone know why this happens – or a way around it – I'd love to hear it. Edit: Looking at other sites where I've used this module, I realise that I only need to include the main.js script (where I have the $.simplecontactform($('.js-simplecontactform')); line). Also, if I put that <script ... main.js\"></script> line inside the <div>, it works fine without duplicating the script on every error.
    1 point
  20. Adds a Service Worker to your Processwire site which can be customised. The service worker script itself is heavily based on Jeremy Keith’s work – thank you Jeremy! More information: https://github.com/johannesdachsel/processwire-serviceworker
    1 point
×
×
  • Create New...