Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 07/04/2017 in all areas

  1. Hi @Pretobrazza and @CodeCoffeeCode - I am sorry for the very long delay in responding - I have just returned from an extended time away from my computer. It looks like the issues you were having with textareas fields and the map marker were actually due to PHP 7. The latest version should fix things - I tested with textareas which now work perfectly again - hopefully map marker fields will also work again now. I have also fixed some other issues with adding multiple new child in Edit mode and also taken care of this issue. Please let me know how things work for you now.
    2 points
  2. Absolutely. Nowadays we build most of the stuff in the back-end with custom Process modules in combined with the forms api. Importing content is also pretty easy. You might ask why not in the front-end? Because the roles and permissions work flawlessly in the backend and the back-end looks pretty good (Reno looks imo the best), but you can create your own based on Uikit. If you want to overwrite the default styling take a look at AdminCustomFiles where you load css and javascript files. Also take a look at MarkupAdminDataTable since most of the stuff you will need is forms and tables. This makes it pretty easy to prototype.
    2 points
  3. Restrict Repeater Matrix Allows restrictions and limits to be placed on Repeater Matrix fields. Requires ProcessWire >= v3.0.0 and FieldtypeRepeaterMatrix >= v0.0.5. For any matrix type in a Repeater Matrix field you have the option to: Disable settings for items (cannot change matrix type) Prevent drag-sorting of items Prevent cloning of items Prevent toggling of the published state of items Prevent trashing of items Limit the number of items that may be added to the inputfield. When the limit is reached the "Add new" button for the matrix type will be removed and the matrix type will not be available for selection in the "Type" dropdown of other matrix items. Hide the clone button when the limit for a matrix type has been reached. Note that in PW >= 3.0.187 this also means that the copy/paste feature will become unavailable for the matrix type. Please note that restrictions and limits are applied with CSS/JS so should not be considered tamper-proof. Usage Install the Restrict Repeater Matrix module. For each matrix type created in the Repeater Matrix field settings, a "Restrictions" fieldset is added at the bottom of the matrix type settings: For newly added matrix types, the settings must be saved first in order for the Restrictions fieldset to appear. Set restrictions for each matrix type as needed. A limit of zero means that no items of that matrix type may be added to the inputfield. Setting restrictions via a hook Besides setting restrictions in the field settings, you can also apply or modify restrictions by hooking RestrictRepeaterMatrix::checkRestrictions. This allows for more focused restrictions, for example, applying restrictions depending on the template of the page being edited or depending on the role of the user. The checkRestrictions() method receives the following arguments: $field This Repeater Matrix field $inputfield This Repeater Matrix inputfield $matrix_types An array of matrix types for this field. Each key is the matrix type name and the value is the matrix type integer. $page The page that is open in ProcessPageEdit The method returns a multi-dimensional array of matrix types and restrictions for each of those types. An example of a returned array: Example hooks Prevent the matrix type "images_block" from being added to "my_matrix_field" in a page with the "basic-page" template: $wire->addHookAfter('RestrictRepeaterMatrix::checkRestrictions', function(HookEvent $event) { $field = $event->arguments('field'); $page = $event->arguments('page'); $type_restrictions = $event->return; if($field->name === 'my_matrix_field' && $page->template->name === 'basic-page') { $type_restrictions['images_block']['limit'] = 0; } $event->return = $type_restrictions; }); Prevent non-superusers from trashing any Repeater Matrix items in "my_matrix_field": $wire->addHookAfter('RestrictRepeaterMatrix::checkRestrictions', function(HookEvent $event) { $field = $event->arguments('field'); $type_restrictions = $event->return; if($field->name === 'my_matrix_field' && !$this->user->isSuperuser()) { foreach($type_restrictions as $key => $value) { $type_restrictions[$key]['notrash'] = true; } } $event->return = $type_restrictions; }); http://modules.processwire.com/modules/restrict-repeater-matrix/ https://github.com/Toutouwai/RestrictRepeaterMatrix
    1 point
  4. FieldtypeFileS3 https://github.com/f-b-g-m/FieldtypeFileS3 The module extends the default FieldtypeFile and InputfieldFile modules and adds few extra methods. For the most part it behaves just like the default files modules, the biggest difference is how you get the file's url. Instead of using $page->fieldname->eq(0)->url you use $page->fieldname->eq(0)->s3url(). Files are not stored locally, they are deleted when the page is saved, if page saving is ommited the file remains on the local server until the page is saved. Another difference is the file size, the default module get the file size directly from the local file, while here it's stored in the database. There is an option to store the files locally, its intented in case one wants to stop using S3 and change back to local storage. What it does is it changes the s3url() method to serve files from local server instead of S3, disables uploading to S3 and disables local file deletion on page save. It does not tranfer files from S3 to local server, that can be done with the aws-cli's through the sync function. Files stored on S3 have the same structure as they would have on the local server. -------------------------------------------------------- -------------------------------------------------------- Been struggling with this for quite a while, but i think i finally managed to make it work/behave the way i wanted. All feedback is welcome!
    1 point
  5. Just working on some smaller projects and take the step into the actual master/dev version and all the new methods and api chunks that are coming with the 3.x series... since i'm not always build websites i'm not always go with the brand new things and put them in my workflow....there is a 24 per day timelimit i think...;) BUT actual i dive deep in markup regions....and holy shit this feature ROCKS! It should put in place better than in some blogposts: http://processwire.com/blog/posts/processwire-3.0.49-introduces-a-new-template-file-strategy/ http://processwire.com/blog/posts/processwire-3.0.62-and-more-on-markup-regions/ or can some admins make a headline in the official docs and link to the blogentries?? This feature is to important to get missed for beginners and other users of PW! I'm just kick my whole workflow and change it for the markup regions....i'm feeling like xmas in summer Thank you @ryan Best regards and happy "new" year....
    1 point
  6. Hi @itsberni - sorry for such a delayed response - I am just back from an extended time away from my computer. I have added a new Bcc email field to the module config settings. All emails will be Bcc'd to the entered address automatically. Please let me know how it goes for you.
    1 point
  7. Hello, I know there are a lot of installing processwire tutorials out there, but here I put mine (with images and other little things) https://dev.to/clsource/installing-processwire hope you like it
    1 point
  8. Thanks clsource for the informations! I finally installed processwire now ready to build awesome site.
    1 point
  9. would you mind adding my suggested features to your module? sorry for not making a PR, but you can just replace your render method with this one: /** * Render the entire markup returned from FieldtypeRuntimeMarkup * */ public function ___render() { //so that $page and $pages are locally scoped to the eval $process = $this->wire('process'); if($process && $process->className() == 'ProcessPageEdit') $page = $process->getPage(); $pages = $this->wire('pages'); // render files that are related to this field $root = rtrim($this->wire->config->paths->root,'/'); $file = '/site/modules/FieldtypeRuntimeMarkup/fields/' . $this->name; if(is_file($root.$file.'.php')) { // we found a file in the modules /fields folder, so render it $str = wireRenderFile($root.$file); } else { // no early reaturn because we load assets later if(!$this->runtimeFields) $str = ''; else $str = eval($this->runtimeFields); } // load assets related to this field if(is_file($root.$file.'.js')) $this->wire->config->scripts->add($file.'.js'); if(is_file($root.$file.'.css')) $this->wire->config->styles->add($file.'.css'); //since we are dealing with custom PHP code but also want to make sure that only markup is returned //if eval() returns anything other than a string or an integer, we throw an error (e.g. if an object or array is returned) if (is_string($str) || is_int($str)) return $str; else return $this->error($this->_('Only strings and integers should be returned by your custom code! Check if your code is valid.')); } this will render all files inside the folder /site/modules/FieldtypeRuntimeMarkup/ - your_field_name.php | .css | .js
    1 point
  10. That works a treat, thanks man!
    1 point
  11. 1 point
  12. All 3 issues above should be fixed in v149, thanks!
    1 point
  13. I think you just need to make sure you don't return from ___uninstall. Throwing an exception should be sufficient, though I haven't tested it. if(! $this->canWeUninstall()) { throw new WireException("Whoops! Module cant be uninstalled as it appears to be in use."); }
    1 point
  14. Why not use http://modules.processwire.com/modules/process-jumplinks/ ? Wouldn't that be less problematic?
    1 point
  15. @jploch The crux is with the transparency of the background. The original image is recognized as a transparent, animated GIF. But the stored transparency color index validates to 0,0,0 (black !) I have opened your image in photoshop and added 1 layer filled with white to the base of the other 60 layers. The animated resulting GIF is same size as yours with transparency but works with the anim module: To sum up: the anim gif module doesn't work in any case with this sort of images. The culprit is the transparency background. If you are able to add a filled background layer to those images, it will work good with resizing. (test the image above) If you also need the transparent background, you cannot use any sort of variation creation. Workaround could be to determine in template file if it is a GIF (or only if it is an animated GIF) and then use markup with a special css class for displaying those in different sizes, according to media query max-width, for example.
    1 point
  16. @jploch I have tested this and created a new Rendering Engine, but for me, every created variation has the same (wrong) result as your example. It is something in that image that doesn't work right with the lib. I think it is a false transparency for every slide in the animation. Are there other images that behave the same? In your "working example" that result in correct variation, I belive it is the original image or simply copy of it. You use ->width(300) and the original is 300px. For me, every downscaled variation doesn't work correct.
    1 point
  17. If you use Tracy you could also dump the object like: bd($page->party_type); It'll save you much time if you know what kind of data you are working on.
    1 point
  18. Thanks for the detailed response @bernhard I havent build a CRM with PW til now, but maybe a pricing table with different prices for different product sizes could be a useful application in my case Best regards
    1 point
  19. Hi there and thanks for a perfect product! PW seems to get more and more popularity, and its flexible power begins even to rival the frameworks like Laravel. I really like PW, and that's why i see some ways to make it even better. Frameworks are often installed OUTSIDE the document root. There's a lot of reasons to do so. Some of them: Security. Every piece of code placed inside docroot is a potential security breach. So we are to keep only a minimal amount of code inside docroot. Website engine obfuscation (and more security again). Anyone can check for presence of /site and /wire folders via http -- and if they're here then it's a Processwire inside webroot with almost 100% probability. Possibility to share the same codebase between several websites placed at the same server (it's really cool!). A nice opportunity to create a static site generator (and PW has it all to become such a generator with minimal coding). But, unfortunately, it's not the case for PW right now. PW is currently designed to be placed only inside webroot. And there's no clear way/guideline how to move PW to an arbitrary directory outside webroot. At least i couldn't find any. OK, there will be however some obvious problems while moving PW outside webroot: Many hosters deny ftp/ssh access above webroot. So it will be impossible to upload/download anything inside /site (at least using ftp/ssh clients). There will be some confusion/ambiguity with /site/assets/files . In most cases they should be accessible via http, so they need to be located inside webroot. But, hmmm, what about 'special' files like hi-res images which are to be protected from occasional downloads? Yes we can write some .htacces to protect them -- but placing such files above webroot is a better practice. Tried to 'bruteforce' my idea by moving /site and /wire from fresh PW 3.x installation one level up my webroot and applying some tweaks to /index.php . No success at this time. Had some core-level errors. PW seems to dislike my experiment, core changes are needed. My whishlist? A possibility to define path (absolute or relative to webroot) for /site (except /assets) and /wire during installation and/or after it via config.php file and/or something like $config inside /index.php . A possibility to separate /site/assets into /webroot/something_like_public_assets (this path should be configurable) and /outside_webroot/something_like_private_assets (this path, of course, should be configurable too). A possibility to change/configure paths after installation. Hope this idea is really important for the future of PW. Will be glad to see a deeper discussion here.
    1 point
  20. This is something I've been doing on a project and it's definitely doable with current (and older) versions of processwire, but it takes quite some work and few patches to have it work. Here's the git repository for it if you want to look into it: https://github.com/t2t2/jury
    1 point
  21. From my experience these shared hosters are exactly the ones without access to folders outside the webroot I don't want to totally invalidate the request for such a feature, it's nice to have options, but I can understand if there's not much priority for it.
    1 point
  22. @LostKobrakai Hello, I (respectfully) do not completely agree on that. .htaccess rules are implemented and forced by the web-server. If there is a security hole in a particular version of the webserver that is reflected onto the website. .htaccess rules do not always work as expected expecially if you are not the one controlling the web-server config (VPS setups or own server). More than one time I had issues with shared hosting. Even directory access protection (basic http auth) stopped working due to global rules invalidating/discarding some of my .htaccess rules that have been working (and still are) for years. And I am not talking about small hosting companies, but big and respectable/respected companies. .htaccess rules is a further layer of security you depend on, not relaying completely on it can be considered an improvement. Thus I always prefer having everything ("upload" folder included) outside the the web doc-root excluding the front script (index.php) and the static assets (or symbolic links to them). I also like to have a customizable directory structure to make things more difficult to guess from attackers. When possible (this does not depend on the cms/framework) I also like restricting php execution to the front script. Over the years (since year 2000 :-)) I've seen many kind of attacks, circumventing well programmed form handlers and uploading code as fake images. So in my opinion having only 1 php file and read-only static assets inside the webroot makes it a lot more difficult for bad guys. It's a feature that I'd like to see in PW and that I asked Ryan about a while ago. kind regards.
    1 point
  23. @elabx Hi, FYI, Adrian is still away for more than a month, see:
    1 point
  24. Security doesn't magically get better just because files are outside the webroot. The .htaccess file does already block all access to critical files inside the processwire installation and all those files must be accessable by the webserver/php anyways, which makes things equally vulnerable in terms of those security holes which let an attacker execute his own code. And as you said for lots of hosting services it's not even an option to put library files outside the webroot. Obfuscation of the system also doesn't really improve anything considerably. Ask all those people here tracking how many attacks on wp-login.php they get even though their sites are obviously not wordpress sites. As soon as security issues are known they'll be tested no matter of how hard you try to mask your underlying system. It's already possible to share the wire folder for multiple sites, but it's to be considered that all pages also need to be updated at once, which at least for me is rather a downside than an important feature. But still this is already doable. Regarding the assets folder. ProcessWire does have a config to protect the whole assets folder essentially piping all requests to files through php to ensure access is granted for each one. If you only need to saveguard some files and prevent the php overhead for the others you can install the 3rd party "SecureFiles" module, which let's you put files out of the webroot when using this fieldtype. In regards to your point about static site generators. ProcessWire is different to Laravel in that it does depend on a database. And not only an empty one, but there need to be things installed to run ProcessWire. That's not really useful if you want some static site. If you only want html output to be generated from db data you can already use ProCache to serve static html to users with the full power of processwire to generate that html.
    1 point
  25. I tried this module today to output a video preview from a multilanguage field. Worked like a charm. See the screenshot. I created two fields, one for the default language (English) and one for Portuguese. Here's the code for both, if someone's interested: English field: return '<iframe src="https://www.youtube.com/embed/'.$page->youtube_id.'/?showinfo=0&amp;iv_load_policy=3&amp;controls=1" frameborder="0" allowfullscreen width="100%"></iframe>'; Portuguese field: //1021 is the 'portuguese' language page id $youtube_id = $page->youtube_id->getLanguageValue(1021); return '<iframe src="https://www.youtube.com/embed/'.$youtube_id.'/?showinfo=0&amp;iv_load_policy=3&amp;controls=1" frameborder="0" allowfullscreen width="100%"></iframe>'; Thanks @kongondo for this great module!
    1 point
×
×
  • Create New...