Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/22/2018 in Posts

  1. Theres a CMS voting on a known german website: https://www.drweb.de/welches-cms-verwendest-web-projekte/ And the interesting part: 5th Place in the ranking is very nice and theres a planned test of processwire on drweb.de 1. WordPress 2. Typo3 3. Joomla 4. Contao 5. Processwire 6. Drupal
    9 points
  2. MBR international is Sudanese mining company. The company aims to maximize shareholder value by through exploration and Production of precious metal and industrial mineral, MBR international mining subsidiary was established in 2015, engaged in Industrial Minerals and Metals mining and related activities including explorations, extraction and processing. **************
    5 points
  3. You can always edit the original post and put "[solved"] in front of the title.
    4 points
  4. Yes, we should get more organized somehow. I agree with the above comments. As a fairly new member of the community I get the impression, that the projects grows more rapidly that the current structures can handle. @ryan - I love the work you (and some in the community) have done so far! I would love to see PW succeed in becoming even easier to use, more feature rich and still beeing stable. I belief with the continued success of the project, more involvement of the community is needed – and therefore an increased focus on coordination from someone (does not have to be you if it's not what you like to do.). One example where I think the current setup hinders this are the separate GIT repositories for issues, code and feature request. I don't know the reasons for this, there might be some good ones I don't know of yet. But from a community standpoint, it makes things complicated and opaque. A central GIT repository would allow the community to participate much better by providing code to PW in the correct context, without much effort using pull requests. Advantages of one central repository would by: Exposure: More bugs get reported because its easier Bugs have better visibility, increasing the reach of developers who can potentially fix it Engagement: Issues can be discussed side by side, draft solutions can be pushed Using pull-requests the community can contribute bugfixes and features in a known way Using milestones, the community can help implement roadmap features Clarity & Code Quality: Bugs, discussions and fixed code live side by side, making things easier to understand Code review make code more stable Marketing: Because there will be more activity on one repository, the project looks more healthy and active for someone judging PW based on this criteria (I myself check issues and activity on open source projects beforehand – if I find no reported bugs and fixes this is a big warning sign) This is just one thing, there are probably other areas where we as a community could support the development of PW better. Im thinking roadmap with milestones etc, semantic versioning, etc. But I suggest to change evrything at once, rome wasn't built in a day Or as our pastor said, same same but a little bit better… Most important, it would be great to have an ongoing discussion about this. I'm in as well As one of only two 80% developers for a church with 60+ locations, I know the need of creating a flourishing community of volunteers firsthand. To take an example: If I can increase my productivity by 20% my project can grow faster by 20%. But if I invest time to onboard 2 others to help me do my work – the project can grow at 200%! I call for many Ryans We need more of the good people on this earth! But for a community to be able to get involved, there needs to be a some (hard) groundwork like simple tools, easy access, clear contribution guidelines, clear roadmaps... A healthy community needs a sense of ownership and unity there needs to be fun etc… I belief that the whole PW universe is amazing, its a great project, @ryan is a great leader, many members are very skilled, polite and very loyal. If we can get more of us to help, the whole ecosystem would greatly flourish – there is tremendous potential in unleashing the full power of the community by letting it get involved easier.
    3 points
  5. Hey thmsnhl, I'm using ProcessWire for a few projects at work as well as for my personal projects. Originally coming from Ruby On Rails I also encountered problems with our database synchronization when it comes to team development on a single project. Depending on the project we solved this using Field/Template Export/Import while also only working on certain parts of the page. Most projects are already finished in terms of template/field structure so there is no need to have an always up-to-date local database snapshot. If the project is not finished in terms of template/field structure we usually sit together and draft a "this-solves-everything"-kind of template/field and synchronize this to our local databases once and then just code ahead. Other frameworks solve this by using Migrations and although ProcessWire does not support Migrations in the core (as of now) you can use this module: https://modules.processwire.com/modules/migrations/ (Here are a few code samples and documentation: https://lostkobrakai.github.io/Migrations/). This module does not directly add tables and columns to the database like RoR migrations do but instead allows you to do nearly everything you can do in the Admin UI using code. You can for example create templates, move fields around, install modules, setup users etc. It can be a bit tedious at first to learn all the new APIs this module offers but the benefits, especially for large projects, speak for themselves. These migrations can be safely checked into your git repository and whenever one of your teammates encounters a problem with his out-to-date database he can simply run the migrations files. So instead of adding templates and fields on production you write them in code and deploy your changes to production, then you migrate either using the CLI utility or the admin backend. You can also integrate this into your build toolchain (like Amazon CodeStar). Check this code example I bet it feels quite familiar: <?php class Migration_2018_01_16_12_32 extends Migration { public static $description = "Add postalcode to a hotel"; public function update() { $this->insertIntoTemplate('hotel', 'postalcode', 'title'); $this->editInTemplateContext('home', 'postalcode', function($f){ $f->label = "Hotel Postalcode"; $f->columnWidth = 50; }); } public function downgrade() { $t = $this->templates->get('hotel'); $t->fieldgroup->remove('postalcode'); $t->fieldgroup->save(); } } This adds a `postalcode` field right after the title field to the hotel template. And it removes this field when you rollback your migration. This is how we tackle this problem.
    3 points
  6. In the module settings you can create your own format. Take a look at the Australia examples - the one with the country code has no leading zero for the area code. My initial suggestion to you would be to create your format based on that. I guess the contingency I never implemented is when you want to be able to call different formats for the same phone field. My initial thought for adding this is to allow you to call the format based on the name of the format in the commented part. So for example if you created a format like this: +1 (23) 456-7890 x321 /* My No Leading Zero With Country: +1 (11) 111-1111 x111 */ you would be able to call it via the API like this: $page->phone->formatted('MyNoLeadingZeroWithCountry'); That way you could create whatever custom formats you need, name them how you want, and call multiple versions on the same field because these wouldn't rely on the format chosen either in the module settings or the field settings. Does this sound ok?
    2 points
  7. Great location and boat though.
    2 points
  8. Still a bit of dummy content at http://mbr-mining.com/news/jl/ (complete with a nice picture of MV Teal on Windermere )
    2 points
  9. I dont think you can. In the previous forum we had years ago, it was "questions and answers" which meant a question could be marked as solved (or having an answer). However, the new system is now a "forum" and is thus a discussion which can not have a definitive answer.
    2 points
  10. This has now been addressed. I've also spent some time spedning up the load of the site by lazy loading alot of the images, however I havent found a nice way of this playing well with Isotope, but works well enough currently.
    2 points
  11. Awesome tip, @Robin S Local history is something I use quite regularly but I suppose I should be committing more often as per the Git mantra Perhaps users who rely on local history can make a backup of the System Cache first before invalidating the cache and seeing what sort of performance gains they get. The locations are : Windows <User home>\.PhpStormXX\system that stores PhpStorm data caches. Linux ~/.PhpStormXX/system that stores PhpStorm data caches. macOS ~/Library/Caches/PhpStormXX contains data caches, logs, local history, etc. These files can be quite significant in size. Source : https://www.jetbrains.com/help/phpstorm/project-and-ide-settings.html
    2 points
  12. Just sharing a tip... PhpStorm had slowed down to a crawl, disk usage was regularly at 100% and the interface was sluggish to the point it was almost unusable. After some googling I found a suggestion to try restarting using the Invalidate Caches option and it has made a huge difference. Now everything is snappy and fast again. More info here, and be sure to read and understand the warnings, especially the fact that your local history will be erased.
    2 points
  13. Nice one! I think the fact that the ID of the original page is not retained when the draft replaces it is a bit of a problem. Because any pages that have a reference to the original page in a Page Reference field will lose that when the draft is published and the original is trashed. This issue is discussed earlier in the thread, and Ryan's suggestion was to copy the content of the draft page to the original page when the draft is ready to go live. Maybe you could look at using that approach?
    2 points
  14. On this cold and rainy weekend in Switzerland, I was trying to learn something about Processwire modules. "Page Draft Control" seemed an ideal starting point, because it has not so many lines of code and looks rather abandoned. While trying to understand it, I've added some code. For me the result looks quite usable, but I am very open for any suggestions, about what could be done better theoretically. I'm not going to further develop this, because there is ProDrafts if you need something perfect. Processwire modules and "ecosystem" are really great. Thank you.
    2 points
  15. https://github.com/thuijzer/processwire-FieldtypeBusinessHours Fieldtype Business Hours ProcessWire Fieldtype for entering business hours (opening hours) Input format Leave a day empty when closed on that day Times are in 24 hour format. 9:00-12:00 9:00-12:00, 13:00-17:30 16:00-2:00 Usage in templates Days are from 1 to 7 where 1 is Monday and 7 is Sunday (ISO-8601) echo $page->field_name->isNowOpen() ? 'Now open' : 'Now closed'; if($page->field_name[1] == null) { echo 'Closed on Monday'; } if($page->field_name[2]->inRange('11:00')) { echo 'Tuesday at 11:00 open'; } echo $page->field_name[1]; echo $page->field_name[1]->getEntries()->getFrom()->format('H:i');
    1 point
  16. On the dev tree it is. Ryan usually incorporates fixes there as soon as he has them ready without bumping the version number up. You can spot that when you look at the commit history.
    1 point
  17. @godmok - obviously an easy fix to ignore blank lines. The issue of the format not being updated is a little trickier - currently the selected format is stored by the format "code", rather than by a name, so changing the definition of a format won't update the format stored for a field. I should probably store formats by their "name" so the current definition for a format is called each time. I think this would be a good improvement for this module and would also be inline with your request to be able to call the format directly. The catch is making sure I don't break existing sites using this module, so I'll have to make this change with that in mind. I'll see what I can do.
    1 point
  18. Hi @adrian, sorry for being late. Now the field works like it should. I was just questioning myself if it would be possible to create own formated numbers and output them. I use something like this on the field input: 49 0123 456 789. On the output I remove the zero from 0123 if there is one. Then in the frontend there is a link with "tel:+" and I can't use the unformatted number, because the number is wrong. Output unformatted output: 490123456789. This should be the own created output format: 49123456789. Best would be formated as +49123456789. In the field settings I have set the format with removing the first number, but how can I get this self made output format easy into the frontend? I have created a function for that, but it would be nice to have individual output format names like: $phone->fomatedNumberNoAreaLeadingZero (fomatedNumberNoAreaLeadingZero would be my own set name in the settings, as example), and the output will be from the settings. Would be nice
    1 point
  19. This is the efficient version. By using substring I avoid creating new page arry in the foreach loop. <?php $text = ""; foreach($page->verspreidingen as $country){ // all countries $text .= "<a href='". $country->url . "'>" . $country->title . "</a>"; $s_out = null; foreach ($page->sub_verspreiding as $state) { // foreach state on the page that is child of a country if ($state->parent == $country) { $s_out .= "<a href='". $state->url . "'>" . $state->title . "</a>, "; } } substr($s_out, 0,-2); if(isset($s_out)) echo " (" . $s_out . ")"; $text .= ", "; } substr($text, 0,-2); echo $text; ?>
    1 point
  20. @fbg13: Good point, thanks. I have incorporated that. Makes the code a lot shorter too
    1 point
  21. Yes, it is true. But this will get too complicated. It's just an exercise for me. Take ProDrafts if you need to cross reference elements by id. It will work in simpler scenarios it think. It is up to the "admin" to decide. At least the original page will remain untouched this way. You can even restore it from trash as if nothing happened. Thank you.
    1 point
  22. Hi guys, BitPoet, you were right, it was a mixture of versions/namespaces in the wire folder. I replaced that and now everything works! I was able to update the entire website to the latest Processwire v. 3.0.62. Thank you all for your help! Ian
    1 point
  23. Very, very alpha but working: https://github.com/BitPoet/ProcessMention
    1 point
  24. In that case, you almost definitely have a mixture of versions in your wire directory. It would probably be easiest to rename the wire directory on the server, re-download 2.6.18 from github at https://github.com/ryancramerdesign/ProcessWire/archive/8964c2d0b5f7d3445adcc5d91467f6117ef0d4fb.zip and upload just the wire directory (make sure to backup the db, though).
    1 point
  25. @CarloC try { echo $modules->get('LoginRegister')->execute(); } catch (WireException $e) { echo "Too many failed login attempts.<br>" . $e->getMessage(); }
    1 point
  26. In addition to @Robin S's suggestion above, if ProcessWire 3.0.87's new features were extended as brainstormed in the post: also adding the possibility for an Images inputfield to upload to and/or pick images from another one (+ this supercharged Images inputfield being filterable) then we would finally have a very impressive set of image management features built in which have been sought after for years.
    1 point
  27. Cheers! Yeah, I guess I should have posted the link here, too. I've been developing with ProcessWire for a few years now (and bugging the community here with whatever issues I ran into -- which so far have always been my own fault!). I just wanted a place where I could explain how and why I picked ProcessWire as my CMF of choice, and to sort of explain a bit how this particular website gets made. I plan to add more to the blog about how some of the stuff works, what my rationale is behind some things, etc. Might not always deal exclusively with ProcessWire, but some upcoming topics will deal with how I handled the watermark branding on social media images (with the great PageImageManipulator module and some creative switcheroo in the PHP code of templates) and how I went about to create the structure and code for a timeline (which isn't online yet due solely to the fact that it has too little content yet). I always like reading patch notes, so I figured I'd add a changelog to the website to keep those who are interested in these kinds of things to keep track of changes that I implement. The roadmap is there to sort of explain where we're going with the website, even if one or two things that are a bit more experimental are kept under wraps (since they may never lead to anything); it also helps remind me what I'm supposed to be working on.
    1 point
  28. Very good article. I also like how they don't hide information regarding developing this website, to include both a Changelog and Roadmap section under their "Dev Index" https://www.ancientworldmagazine.com/dev/
    1 point
  29. Interesting read and a very nice PW site: https://www.ancientworldmagazine.com/dev/blog/built-using-processwire/
    1 point
  30. I like to keep things light. I'd say look into Foxycart or Snipcart, or Moltin. Either solution still allows you to use ProcessWire while handling off commerce functionality to those other systems. Or you could built it entirely in ProcessWire like I did. Not recommended unless you really want to get your hands dirty. A lot of re-inventing the wheel (although a good learning experience).
    1 point
  31. These are called bugs....
    1 point
  32. Using wireSendFile() for flexible download is great to mask the real file location on the server or to select the file according to the language, but it comes with an issue that appears for large files or slow connections: until the download completes, any other access to the website from the same session is blocked. For a user viewing a page that contains such a download link, this means that when he clicks on the download link, the download starts as expected, but until the download completes, the user can not navigate to a different page of the site, which is probably not the expected behavior. The solution to avoid this issue is to call session_write_close() before wireSendFile(), like this: $options = array( // boolean: halt program execution after file send 'exit' => true, // boolean|null: whether file should force download (null=let content-type header decide) 'forceDownload' => true, // string: filename you want the download to show on the user's computer, or blank to use existing. 'downloadFilename' => $clientFilename, ); // Close the php session, so wireSendFile doesn't block other connections from the same session while downloading session_write_close(); wireSendFile($serverFilePath, $options); This should not have any unwanted effect as long as the 'exit' option is set to true (because wireSendFile() calls exit() just after readfile() in this case). Note: The issue comes from PHP's session management, where "session data is locked to prevent concurrent writes only one script may operate on a session at any time" (as says PHP session_write_close documentation ). A google search "php readfile session_write_close" brings many exemple of this lock problem.
    1 point
  33. Adam, your original selector would have worked, but it's an oversight. Technical explanation: That the second find() is going through WireArray::find() rather than $pages->find(). The WireArray::find is all done in memory, whereas the $pages->find() actually translates to a database query. The two are supposed to function similarly from API, but the WireArray version is missing a few things present in the $pages version (undocumented things, see below). The "sort=random" is one of those things, but no longer… I just fixed that in the latest commit, so your original selector should now work in the latest P21. https://github.com/ryancramerdesign/P21/commit/f083f7d4d433d6c0919101f2c17b15059b6ab2b4 For reference, the other [undocumented] things not yet implemented in the WireArray version are: status=hidden status=unpublished status=locked status=max include=hidden include=all check_access=1 sort=a, sort=b, sort=c (sorting by multiple fields) These will all be implemented, and then documented once consistent across the $pages->find() and WireArray::find() versions. Beyond the above undocumented items, the two should otherwise function the same at present. Also note that Pete's version is a good way to go, and perhaps more efficient than using a second selector.
    1 point
×
×
  • Create New...