Leaderboard
Popular Content
Showing content with the highest reputation on 07/31/2019 in all areas
-
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!1 point
-
Please don't use this module any more. I think in the end it just adds more complexity (and dependencies) than benefits. See this tutorial how simple it is to create a custom runtime-only Inputfield: WHY? I've started building this module because the existing solutions by @kongondo and @kixe (https://modules.processwire.com/modules/fieldtype-runtime-markup/ and https://github.com/kixe/FieldtypeMarkup) did not exactly fit my needs. Actually this module is aimed to be a base module that can easily be extended by other modules. It takes care of the heavy lifting that has to be done when working with custom fieldtypes in ProcessWire (injecting scripts and styles, handling JS events, doing translations). See RockTabulator as an example. I'm quite sure more will follow (eg ChartJS)... WHAT? This module helps you injecting ANY php/html/js/css into any PW backend form (either on a page or in custom process modules). It also comes with a sandbox process module that helps you setup your fields and provides handy shortcuts that integrate with TracyDebugger and your IDE: WHERE ...to get it? At the moment the module is released as early alpha and available only on github: https://github.com/BernhardBaumrock/RockMarkup2 If you have any questions or ideas please let me know ? PS: This module shows how easy it is to extend this module for your very own needs. All you need to do is providing the module's info arrays and then overwrite any methods that you have to modify (eg the InputField's render() method): https://github.com/BernhardBaumrock/RockMarkupExtensionExample1 point
-
This is a small tutorial... If you want add another field to this fieldtype... first in FieldtypeEvents.module in getDatabaseSchema() add a line that suit your needs, so your new field gets stored to the database $schema['newValue'] = 'TINYTEXT NOT NULL'; try if you can install the module and add a field to a template and check if it works like before add the property to the constructor in Events.php $this->set('newValue', ""); then modify set() and get() so you can modify your new property... now try in your template,´if you can modify and output the new property foreach($page->events as $event){ $event->newValue = "hello new value"; echo "yes it works, we we welcome the new value: ". $event->newValue."<br>"; } if this works properly then go back to FieldtyeEvents.module: add this line in __wakeupValue() to the foreach loop $event->newValue = $v['newValue']; and in _sleepValue() 'newValue' => $event->newValue, in file InputfieldEvents.module in renderRow() method make sure, a $newValue variable gets gets sanitized from $newValue = $this->sanitizer->entities($event->newValue); change $out = " <tr class='Event$cnt $class'> <td><a href='#' class='EventClone'><span class='ui-icon ui-icon-copy'></span></a></td> <td><input type='text' name='{$name}_date[]' value='$date' class='datepicker' /></td> <td><input type='text' name='{$name}_newValue[]' value='$_newValue' /></td> //add this line add your field in __render() <table class='InputfieldEvents'> <thead> <tr class=''> <th class='EventClone'> </th> <th class='EventDate'>Date</th> <th class='EventDate'>newValue</th> //I´ve chosen EventDate class because its narrow and in __processInput() $event->newValue = $input->{"{$name}_newValue"}[$cnt]; I hope I didn´t forget anything, good luck!1 point
-
1 point
-
The easiest way is to set the options page in the _init.php file: $siteOptions = $pages->get('/options/'); // If you set setFunctionsAPI ( $config->useFunctionsAPI = true; ) to true in the configuration file, you can display them in the template in this way $siteOptions = pages()->get('/options/'); //or $siteOptions = pages('/options/'); Then in the template just display the fields: <h1><?= $siteOptions->site_name ?></h1> <?php // In the field settings you should select to display a single image if ($siteOptions->logo): ?> <img src="<?= $siteOptions->logo->url ?>" width='100' alt="<?= $siteOptions->logo->description ?>"> <?php endif ?> Or add new “Unique” status for pages https://processwire.com/blog/posts/pw-3.0.127/ Add this status to the Options page and in the _init.php file get this way: $siteOptions = pages()->get('options'); // or $siteOptions = pages('options');1 point
-
Hi @Neo, I gave a quick view to your virtual host conf file and it seems ok. However I see you are using SSL and virtual host:80 automatically rewrites to https. I guess you just did not mention, but just to double check... do you have a second virtual host for https? I have a second virtual host:443, which, if I well recall was created by Letsencrypt with a name similar to example.com-le-ssl.conf, and that also needs to be enabled. You may wish to have a look at apache error.log/access.log as this could help to identify what is the cause of the problem. Last question, is PW installed in the root directory (likely ?) or in a subdirectory?1 point
-
I use sass with tailwind. Also in my opinion purgecss is must have with tailwind to remove all unnecessary css. This is a good read, it nails just how I have felt about BEM and many other ways to css: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ I do like vanilla css, but writing scalable, easy to maintain css is very difficult. Tailwind helps me a lot regarding that and doesn't take away css/sass/less when I want it. My first reaction to utility frameworks was that those are worst idea ever. Glad I gave em chance!1 point
-
Some updates for AdminBar in the latest release (1.1.0): Got rid of the jQuery dependency. Not a big deal, but that's still one setting and one dependency less. As a result the module probably won't work as expected in IE < 11, so if someone is still stuck with ancient browsers, it's better to stay with version 1.0.7 (tagged in the GitHub repository). Some minor optimisations and tweaks here and there. Nothing major, really. Just tested @tiress styles, and they seem to still work as expected, so most custom themes are likely unaffected ? For the record, I'm thinking of releasing a 2.0.0 of this module pretty soon. This would be a breaking change, and require ProcessWire 3.x, PHP 7.x, etc. I'm also thinking of moving custom styles out of the module directory so that the whole directory can be safely removed during updates.1 point
-
1 point
-
Watch out. More is coming! ePrivacy Regulation - kind of an update or maybe even upgrade to the existing GDPR. You might want to read about it at your local law/privacy blogs - trust only professionals in this case and don't look for answers on any marketing blogs, please. This regulation is long overdue and will give us new chances and possibilities to hit the desk with our heads. While it seems to be a good thing in some kind, like the GDPR, it might backfire as well and might hit the smaller ones once again.1 point
-
1 point
-
I use FieldtypeYaml module because it is relatively easy to manually edit Yaml. JSON is easy to read but not so easy to manually edit. It is a good choice using FieldtypeYaml for not too complex config fields , I think.1 point
-
Well, I'm no pro at this and you could probably improve it, but here's my attempt which serves my current needs pretty well: /** * Creates a repeater field with associated fieldgroup, template, and page * * @param string $repeaterName The name of your repeater field * @param string $repeaterFields List of field names to add to the repeater, separated by spaces * @param string $repeaterLabel The label for your repeater * @param string $repeaterTags Tags for the repeater field * @return Returns the new Repeater field * */ public function createRepeater($repeaterName,$repeaterFields,$repeaterLabel,$repeaterTags) { $fieldsArray = explode(' ',$repeaterFields); $f = new Field(); $f->type = $this->modules->get("FieldtypeRepeater"); $f->name = $repeaterName; $f->label = $repeaterLabel; $f->tags = $repeaterTags; $f->repeaterReadyItems = 3; //Create fieldgroup $repeaterFg = new Fieldgroup(); $repeaterFg->name = "repeater_$repeaterName"; //Add fields to fieldgroup foreach($fieldsArray as $field) { $repeaterFg->append($this->fields->get($field)); } $repeaterFg->save(); //Create template $repeaterT = new Template(); $repeaterT->name = "repeater_$repeaterName"; $repeaterT->flags = 8; $repeaterT->noChildren = 1; $repeaterT->noParents = 1; $repeaterT->noGlobal = 1; $repeaterT->slashUrls = 1; $repeaterT->fieldgroup = $repeaterFg; $repeaterT->save(); //Setup page for the repeater - Very important $repeaterPage = "for-field-{$f->id}"; $f->parent_id = $this->pages->get("name=$repeaterPage")->id; $f->template_id = $repeaterT->id; $f->repeaterReadyItems = 3; //Now, add the fields directly to the repeater field foreach($fieldsArray as $field) { $f->repeaterFields = $this->fields->get($field); } $f->save(); return $f; } And here's an example of calling it: $f = $this->createRepeater("sc_promos","sc_promo_active sc_promo_code sc_promo_discount","Promotional Offer","shoppingCart"); You can then use $f to add your new repeater field to a fieldgroup/template.1 point