Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/25/2014 in all areas

  1. AlternativeGridImages module for Processwire Details Add a slider directly proportional to the size of the images introduced in the input field image. Installation copy AlternativeGridImages folder to /site/modules/ Screenshot https://github.com/LuisSantiago/AlternativeGridImages Updated 1.0.6: - Renamed altGrid as AlternativeGridImages. (Thanks @adrian) - Changed styles. - The slider value is saved in a cookie. (Thanks @Martijn Geerts) Updated 1.0.7: - Limit the number of characters in the file name (all items have the same height) (Thanks @enricob)
    9 points
  2. It could be that you have some output formatting applied in the field settings. In that case you should first get the Unix timestamp, like this: $month = date("F", $page->getUnformatted("date")); // where date is your fieldname
    4 points
  3. This should do it if your date is already formatted: $month = date("F", strtotime($page->date)); //strtotime converts a formatted date string back to a unix timestamp
    4 points
  4. I love what you've done here! Just a few small things. Modules in PW need to be named with an uppercase letter for each component of the name, eg: AltGrid - each file and the class should be named like this. Even though you can install it manually the way you have it now, it can't be installed automatically. Maybe a personal thing, but I'd like to see a little padding between each image in the grid. Any chance of storing the slider value so that it loads the last selected percentage? And/or have the % configurable in the module settings? Nice work - thanks!
    4 points
  5. If you only want to be a web developer my advise would be to look for a web developer job. People tend to forget about the most important part of being a freelancer: networking! You have to be good in communicating with people. That means being open, talk to people (getting to know them, etc.), especially in the beginning when you're not a big deal yet. And as pwired already mentioned probably the most dificult task as a web designer is to find out what the client wants even though the client doesn't know that himself (or just isn't able to tell it). The coding/designing part is in fact the easiest! At least, that's what I experienced...
    3 points
  6. The php date function needs a unix timestamp. $month = date("F", 1408946806); // here's the $page->date replaced with the value. echo $month; // outputs: Augustus
    3 points
  7. Have a look here https://processwire.com/talk/topic/5594-page-1322-is-not-valid-for-some-page-name/ Edit: Beaten again! Scores 2- 1 to Adrian
    2 points
  8. Also, what about the possibility of setting up the slider with step options so it snaps to 1,2,3,4,5 images across? You could either use this approach: http://jsfiddle.net/3a2Tx/3/ if you want to keep it in %, or maybe change the slider to the number of images across with a simple step="1" and then convert these to the required % value.
    2 points
  9. @Vizz. Your site does not seem to be a ProcessWire website. I am moving this to 'Pub - Dev Talk for now. I am giving you the benefit of doubt that you are not a spammer . If you have any specific questions regarding ProcessWire please post in the appropriate forums. I've edited the topic title since it read like you are just advertising your own web development business (nothing wrong with that) but in the guise of asking a question. I have also deleted a link to your site.... for now...
    2 points
  10. Cool. Now you just need a Readme.md (you will eventually need this if you want to submit your module to the modules' directory. Then again, your module might just make it to the core(!) )
    2 points
  11. Maybe this can be done with a cookie, store the width of the image in an array of templates. This way the image width settings can be different from each template.
    2 points
  12. Nice one Sinnut - for some reason I always forget about "getUnformatted" - that is definitely the right PW way to do it and I guess one less conversion step along the way!
    2 points
  13. Try looking on the official PW documentation tutorial it contains all you need. You may also want to look at some video tutorials.
    2 points
  14. @Marinus, Thanks for testing Blog. Sorry for your pain in respect of manually removing leftovers. I personally don't like to remove leftovers manually! Before I get into details why that is an intentional feature, from your post I can observe that despite clear instructions in the first post in this thread as well as notes both in the GitHub project home and the module directory, and despite the fact that these are either typed in coloured or bold font, you did not (at least not entirely) read the instructions and/or notes . Just in case others miss them, this is what I am referring to: From the first post in this thread: From the modules directory and GitHub 'notes' sections. If you'd read the instructions and the notes, not uninstalling 'much' would not have come as a surprise .. Yes, I know my reason for not removing everything was not explicitly explained in the notes. Maybe I should add this to the first post but back to your question.... A module like Blog is a complex application. No matter how smart it is there is no way it can second-guess the various ways in which it will be used by the client. For instance, the module installs various fields. What if the user decided to reuse the Blog fields in their other templates? What if they decided to reuse some of the templates or add other code in the template files? What if they'd built their Blog content over time and down the road decided they no longer needed the full Blog experience but wanted to keep some or all of the Blog pages? If uninstalling Blog uninstalled everything.....well, you get the picture. This is something I thought long and hard about and also consulted on before making the call that "rather a painful manual uninstall than potentially destroying a user's data on uninstall!". . There's good news though..(OK, maybe not for you but others since you've already uninstalled Blog... )....... I already have a script that will remove all traces of Blog - fields, templates, template files, pages. The script was written before I released Blog. I was reluctant to post it but maybe now I should (as a Gist). I would like to package it better though rather than something that will run immediately the file is loaded. I am thinking of packaging this with prompts (are you sure you want to delete?!!), maybe even make it configurable to allow selection of what you want to remove from your current Blog install. Now that I mention this, I might follow up on an idea a friend suggested a while back. Maybe something for Blog 2.0 (if we ever get there ) - make the whole Blog install configurable - i.e. on install, the user decides what aspects of Blog they want to install. They don't want comments? Fine. They want to call Blog Posts 'News'? Fine, we can do that...etc, etc... Anyway, I hope I have answered your question somewhere in there UPDATE: Blog version 2 now removes its path of trash (rather than leave them behind ). It also allows you NOT to install commenting feature plus other stuff.
    2 points
  15. The Module Blog for ProcessWire replicates and extends the popular Blog Profile. Blog is now in version 2. Please read the README in the Github link below in its entirety before using this module As of 20 December 2017 ProcessWire versions earlier than 3.x are not supported Blog Documentation is here (Work in Progress!) See this post for new features in version 2 or the readme in GitHub. To upgrade from version 1, see these instructions. ################################################## Most of the text below refers to Blog version 1 (left here for posterity). Blog version 1 consists of two modules: ProcessBlog: Manage Blog in the backend/Admin. MarkupBlog: Display Blog in the frontend. Being a module, Blog can be installed in both fresh and existing sites. Note, however, that presently, ProcessBlog is not compatible with existing installs of the Blog Profile. This is because of various structural and naming differences in respect of Fields, Templates, Template Files and Pages. If there is demand for such compatibility, I will code a separate version for managing Blog Profile installs. In order to use the 'Recent Tweets Widget', you will need to separately install and setup the module 'MarkupTwitterFeed'. Please read the README in the Github link below in its entirety before using this module (especially the bit about the Pages, etc. created by the module). I'll appreciate Beta testers, thanks! Stable release works fine. Download Modules Directory: http://modules.processwire.com/modules/process-blog/ Github: https://github.com/kongondo/Blog You can also install from right within your ProcessWire install. Screenshots (Blog version 1) Video Demos ProcessBlog MarkupBlog Credits Ryan Cramer The Alpha Testers and 'Critics' License GPL2
    1 point
  16. Field dependencies are coming in ProcessWire 2.4, and I just wanted to give you guys a little preview of it. The development of this new feature is being sponsored by Avoine, the company where Antti works (he also specified how it should work). Field dependencies are basically just a way of saying that one field depends on another. It dictates which fields should be shown in a given context. In our case, it also gets into whether a field is required or not. This short video demonstrates how it works: (switch to the 720p and full screen version, as YouTube's default settings for this video make it impossible to see): // Edit @Adamkiss: Here's link for those on mobile: youtu.be/hqLs9YNYKMM The implementation here is done both client-side and server side. Javascript handles the showing/hiding of fields and the required vs. not required state changes. On the server side, it doesn't process any fields that aren't shown, and honors the required rules. A separate processing occurs both client side and server side, ensuring that the user can't make their own rules by manipulating the markup or post data. These field dependencies can be used with any Inputfield forms. That means you'll be able to use it not just in ProcessWire, but in FormBuilder, and via the API too. It's very simple to use from the API. All you have to do is specify a ProcessWire selector to either "showIf" or "requiredIf" to the Inputfield, and ProcessWire takes care of the rest: // show this field only if field 'subscribe' is checked $inputfield->showIf = "subscribe=1"; // show this field only if 'price > 0' and at least one category selected $inputfield->showIf = "price>0, categories.count>0"; // make this field required only if 'email' is populated $inputfield->required = true; $inputfield->requiredIf = "email!=''"; This feature will be in the 2.4 core (rather than as a separate module), so it will also be ready and available for things like module and field configuration screens.
    1 point
  17. Hey, I just thought it might be helpful to have a guide for your module's presentation: The Title The title of a module is an important part of it. It should kind of make the main function of a module understandable after the first reading. So there are some guidelines for naming a module: (via http://processwire.com/api/modules/) Here is a more extended list of some "module prefixes" and a short description for each: (via http://processwire.c...-module-naming/) The Description A good description is another important part of your module's presentation. Here is a short list of sections you could (or maybe should) include in it: General: The main function of your module How to use: A description of how to use your module which maybe includes some details the user won't see directly. Installation: If there is something special about the installation of your module you should add this to your description. Screenshots/-casts: It's awesome if you would take a picture of your module (if it changes or adds something the user is able to see). Or maybe a screencast if you like to. (Great example: http://processwire.c...ncy-admin-mode/) Links At the end of your post you should add some links like where the user can download the plugin and if you've added your module to the module section you should post the link here too. Module Section If you've posted your module already to the modules section you can easily copy it's contents there and use them for your post here or - of course - the other way around. I hope this post was helpful to you. Greets, Nico
    1 point
  18. Hi! Just currently using this on our proof of concept and on a hackaton. It's like ServicePage module but the difference is it return data without the need of extra programming (Image field for example). Also it only coded on the template. It primary used template URL segment to identify what page should be returned. All output is generated in JSON format. You can view it here.
    1 point
  19. @Mel: here is a post that describes how to use a watermark that is uploaded into a single image field (to make an image field a single image field you have to setup the field to only allow 1 file, otherwise, 0 or greater 1 it is a multiple files field): https://processwire.com/talk/topic/4264-release-page-image-manipulator/#entry41883 The general how to you can read in the initial post here in this thread: The $pngAlphaImage can be a filename (full path and not an url!) or a pageimage. Example with filename, assumed you have uploaded a png watermark image per FTP to your server into a directory besides wire and site, called "_mystuff": $png = $_SERVER['DOCUMENT_ROOT'] . '/_mystuff/' . 'basename-of-my-watermark.png'; foreach($images as $image) { $watermarked_image = $image->pimLoad('tw', true)->width(500)->watermarkLogo($png, 'southeast', 0)->pimSave(); echo "<img src='{$watermarked_image->url}' />"; } An example with png from an imagefield, assumed it is called 'watermarkfield' and is on a page with the name/url '/tools/'. The tools page isn't visible from the frontpage, it is only a page that holds some fields and stuff that I need around the site on different places: // assumed the watermarkfield is a single image field: $png = $pages->get('/tools/')->watermarkfield; // assumed the watermarkfield can have multiple images and I want use the first one: $png = $pages->get('/tools/')->watermarkfield->first(); foreach($images as $image) { $watermarked_image = $image->pimLoad('tw', true)->width(500)->watermarkLogo($png, 'northwest', 0)->pimSave(); echo "<img src='{$watermarked_image->url}' />"; }
    1 point
  20. Regarding to the above, a curious fact is that you can update most wordpress sites without admin privileges. example: http://demo.opensourcecms.com/wordpress/wp-admin/upgrade.php
    1 point
  21. In other browsers drag and drop works on the input button to add files ( without ajax ), if that works in IE it's almost like the html5. Haven't tested on IE9. A polyfill? https://github.com/Jahdrien/FileReader caugh.. dependencies, I don't know...
    1 point
  22. Do either of these help shed any light on the problem? https://processwire.com/talk/topic/5594-page-1322-is-not-valid-for-some-page-name/ https://processwire.com/talk/topic/5083-possible-bug-page-fieldtype-with-custom-selector-to-find-selectable-pages-returns-error-while-saving-page/
    1 point
  23. ufff, just thinking... would a onchange on the file input with triggering the save button help as workaround? Maybe bombined with a add hash to form action url to jump to image field? Kinda hacky but should work fine. $('#ProcessPageEdit #Inputfield_images').on("change", function(e){ $("#ProcessPageEdit").attr("action", $("#ProcessPageEdit").attr("action") + "#Inputfield_images"); $("#submit_save").trigger("click"); });
    1 point
  24. Is the template access denied from guest user? Public pages will still use normal "unsecure" folders, only the templates that are restricted get secure files.
    1 point
  25. Usually they don't break but display the mobile version if a "mobile first" approach is applied. If IE8- should be supported, I would rather polyfill the media queries for them. But I think this is a more a religious question
    1 point
  26. Soma has a good point - at the moment if you have more than one image field on a page, the slider only shows up on the first one, but it controls the images on all of them.
    1 point
  27. What if you have multiple image fields on page? Or a image field with only max 1 image? And also one field with slider and field without?
    1 point
  28. Great improvements blad! The only thing I noticed is the sizing when you first load a page after installing the module - that is before the cookie is set for the first time - the slider is set to the left edge, but images in the grid were at three across (I think it was 3). So you grab the slider handle and move, but it instantly goes to maybe 10% because that's the position of the slider. From then on everything seems to work brilliantly! PS I still like the idea of being able to set the default width in the config settings, and maybe even an option to disable the adjustment slider - some users are easily confused You could maybe even make the slider available to some some user roles and not others, but I am probably getting carried away with things that really aren't necessary
    1 point
  29. By video embedder, do you mean tools like videojs, mediaelementjs, sublimevideo ? If so, you might find my Video fieldtype module useful. Along with support for uploading videos, it also has native support for playing the videos using sublimevideo by simply doing: echo $page->video_field->eq(0)->play;
    1 point
  30. + the field names that make sense for the full 100%. +100% never calling customers, simply cause they are satisfied for the 100%.
    1 point
  31. Blad, this looks sweet! Here's some resources to guide you regarding ProcessWire modules (naming conventions, etc.) http://processwire.com/api/modules/ https://processwire.com/talk/topic/2394-how-to-present-your-module/ https://processwire.com/talk/topic/741-a-guideline-for-module-naming/?p=6267
    1 point
  32. @adrian getUnformatted is definitely the PW way , but i'm not entirely sure that it saves a conversion step. Seeing as a datetime field is a Y-m-d H:i:s field on the database side of things a strtotime is always necessary. I've always thought that getUnformatted on a datetime field gives you the wakeupValue: // in FieldtypeDatetime.module /** * Convert value from Y-m-d H:i:s string to timestamp * */ public function ___wakeupValue(Page $page, Field $field, $value) { if(empty($value)) return ''; $value = strtotime($value); if($value === false) $value = ''; return $value; } I'm guessing this wakeupValue is always present, if thats the case it does indeed seem to save a conversion
    1 point
  33. Well getUnformatted is in the cheatsheet. Are you referring to the date function not being in there? Only reason is that it's a pure PHP function, rather than something that is part of the PW API so it doesn't really belong. I feel like it might belong in here (http://processwire.com/api/fieldtypes/) once Ryan gets around to adding info about the datetime fieldtype.
    1 point
  34. Hi and welcome to PW dupalski, I would suggest to take a look at the basic site profile that comes with the pw installation and analyse how it is done. The profile is already a simple website by itself. However, to succeed with PW at least basic HTML and CSS knowledge is required along with some (very, very) basic PHP skills (or the will to learn it). Different to that, one can get results with WP without HTML and CSS knowledge.
    1 point
  35. There is no need for special API formatting - just make use of the PHP date function: http://php.net/manual/en/function.date.php $month = date("F", $page->date);
    1 point
  36. I need to do some more slider images and get some more up to date content, but the bulk of the work is done. I did a blog, and google calendar. Responsive since I used Bootstrap 3. Feedback is appreciated! Thanks! http://www.trinitytxk.com/
    1 point
  37. I think I got the scroll bar issue fixed! Thanks for pointing that out!
    1 point
  38. Suddenly had a bright idea. The missing pages were set to "hidden". I needed to use: $results = $pages->find("url_old!='',include=hidden"); I'm leaving this page as a monument to my own stupidity.
    1 point
  39. Just for the record, since it's closely related to this thread, there's a pull request in GitHub about SQLite support (opened back in May). There are quite a few changes and most likely it isn't in sync with current dev branch (it's based on the master branch), but still works as a nice proof of concept for SQLite support. If any SQLite user here is able to get that one running and could run a few tests to see how well it behaves (the questions Ryan asked in his comment to the PR, like how well selectors work etc.) it would be interesting to hear.
    1 point
  40. I think it would be rather $products = $pages->find("template=product, (product_name=computer), (product_category=electronics)");
    1 point
  41. For processwire: what about a review process for approving new modules ? Or a module that scans for vulnerabilities and inform when it finds vulnarable code ? ============================================= It is not just the number of available plugins going around but certainly also about lazy webmasters. There is a lot that webmasters can do to reduce hacks and plugin exploits 1. Change a default table prefix into something like bhsug479_ and it will make sql injection less easy. 2. prevent script injection, and unwanted modification of _request and or globals: # protect from sql injection Options +FollowSymLinks RewriteEngine On RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR] RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR] RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) RewriteRule ^(.*)$ index.php [F,L] 3. Reduce ip access to the admin to a static ip or a limited ip range # deny access to admin order deny,allow allow from xx.xx.xx.xx # static IP or limited IP range deny from all 4. Limit Access to important directories Order deny,allow Deny from all <Files ~ “.(xml|css|jpeg|png|gif|js)$”> Allow from all </Files> 5. Protect config.php files # protect config.php <files config.php> Order deny,allow Deny from all </files> 6. # disable directory browsing Options All -Indexes use empty index.html files Hide a plugin folder with an empty index.html 7. # protect your .htacces files <Files ~ "^.*\.([Hh][Tt][Aa])"> order allow,deny deny from all satisfy all </Files> 8. Prevent the admin section from being indexed. 9. Set a .htaccess password on the admin directory 10. Choose safe chmod permissions depending on the user-id of the running server and your hosting type. http://phpsec.org/projects/guide/ 11. Change the admin url into something cryptic and prevent it from being site browsable 12. Create a new administrator account with a name that is hard to guess Then delete the default administrator account 13. Restrict the number of failed logins in a limited time window. Do not echo wrong login error messages as this is feedback to a hacker 14. Move important files and directories one level above your site root on the server.
    1 point
×
×
  • Create New...