Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 05/23/2017 in all areas

  1. The good reason here is being a content-management system and not a layout-factory of sorts. It's there to store content, while being concerned as little as possible about whichever way the content will be served to the user. This is up to the developer to decide/implement. In fact it's rather the opposite. E.g. drupal is recently trying to shift more towards being a potentially headless cms, which is not coupled to any kind of output strategy (html+css is only one possibility). With the shift to more and more content being served over multiple channels at the same time (website + api / website + mobile app / …) it's also needed to have this freedom. But as I said it always depends on the individuals situation. If you need something to click together the layouts in the backend ProcessWire might not be the best fit.
    3 points
  2. To my way of thinking, numeric IDs are the worst case in terms of being editor friendly. I see HannaCodeDialog as being a kind of progressive enhancement of Hanna Code, such that in the future you could uninstall HannaCodeDialog and still have tags that an editor can understand and use. But with numeric IDs you'll have tags along the lines of... [[my_tag file="34784" options="4745|9748|8985"]] And that seems contrary to the whole idea of Hanna Code, which is about giving editors easy to understand options while you the developer do the heavy lifting (be it matching editor-friendly names to IDs or whatever) behind the scenes in the tag code. Having said that, I'd like the module to be flexible and let devs decide for themselves how they want to use it. So happy to announce... HannaCodeDialog v0.1.2 Inserting a tag from the dropdown no longer opens the dialog if the tag has no editable options. A new method prepareOptions() can be hooked in order to define or manipulate the options that can be selected for a tag attribute. See the module readme for more. @LMD, you can hook this new method to set separate value and label as per your proposal: $wire->addHookAfter('HannaCodeDialog::prepareOptions', function($event) { $options = $event->return; $new_options = array(); foreach($options as $option) { if(strpos($option, '@@') !== false) { list($value, $label) = explode('@@', $option); $new_options[$value] = $label; } else { $new_options[$option] = $option; } } $event->return = $new_options; });
    3 points
  3. @Robin S Just an FYI. I followed your procedures to export my local dev profile and install it to my live server. Everything went without a hitch. I owe you a coffee, a beer, and a pizza!
    3 points
  4. Installing via "Add module from URL" is nearly as easy: https://github.com/somatonic/ClearCacheAdmin/archive/master.zip But I agree it would be great to have this module in the directory.
    2 points
  5. Came to ask pretty please for this, I sometimes work in the harsh lands of Only FTP Access and Detrimental Server Features and oh boy, deleting the cache gets rough. I really miss just writing ClearCacheAdmin class on the module install :')
    2 points
  6. ProcessWire is missing a CLI installer for a long time. You might want to take a look at how wireshell or tense did handle the task of automating installs. Edit: And starting from an base install you could easily bootstrap things further with my Migrations module.
    2 points
  7. Hi @rick, I can't share my custom profile because it contains pro modules. And it's set up to suit my preferences and idiosyncrasies which would surely be different for each person. But it's very easy to make your own custom profile. If you find yourself installing the same modules or creating the same kinds of page structures over and over for each project then the idea is: Create a new installation on your localhost using the "blank" profile Customise /site/config.php how you like, e.g. imageSizerOptions, useMarkupRegions, setlocale() Install your favourite modules - include the Site Profile Exporter Set up any admin tweaks with AdminOnSteroids and/or AdminCustomFiles Create the fields, templates and template files you tend to need for every new site (it doesn't hurt if there are some that aren't always used as you can always delete them in any project that doesn't need them) Create any page structures you want to have pre-existing (I have a "news" section, and a "selects" section for Page Reference options) Export your site profile Then when you are creating a new project you just copy the profile folder to the root before installing PW and select it during the install process. I keep my starting profile on localhost and update/re-export it from time to time with the latest module upgrades and any new tricks and tweaks I have learned.
    2 points
  8. Introducing our newest [commercial] module: Recurme Processwire Recurring Dates Field & Custom Calendar Module. http://www.99lime.com/modules/recurme/ One Field to Recur them ALL… A Recurring Dates InputField for your Processwire templates. The InputField you’ve been waiting for. Complex RRule date repeating in a simple and fast user interface. Use the super simple, & powerful API to output them into your templates. example: <? // easy to get recurring events $events = $recurme->find(); // events for this day $events = $recurme->day(); // events for this week $events = $recurme->week(); // events for this month $events = $recurme->month(); ?> <? // Loop through your events foreach($events as $event){ echo $event->title; echo $event->start_date; echo $event->rrule; echo $event->original->url; ... } ?> Unlimited Custom Calendars. Imagine you could create any calendar you wanted on your website. Use recurring events with the Recurme field, or use your own Processwire pages and date fields to render calendars… it’s up to you. Fully customizable. Make as many calendars as you like. Get events from anywhere. Recurme does all the hard date work for you. Unlimited Custom Admin Calendars too. Hope you like it , Joshua & Eduardo from 99Lime. ## [1.0.1] - 2017-05-29 ### changed - Fixed $options[weekStartDay] offset in Calendar - Fixed ->renderCalendar() Blank Days - Fixed missing ->renderList() [renderMonth][xAfter] - Removed ->renderCalendar() <table> attributes border, border-spacing - Fixed ->renderCalendar() excluded dates - Fixed rrule-giu.js exclude dates - Fixed ->renderList missing space in attr ID (shout out to @Juergen for multiple suggestions & feedback).
    1 point
  9. Are you talking about inputfield dependencies? From the docs...
    1 point
  10. If you need extra customisation, try out ParsedownExtraPlugin.
    1 point
  11. Hi @Chris Falkenstein You can use markdown or textile syntax in description of fields
    1 point
  12. I'm using it for well over 1 and a half years in a production project and to be honest, what you'll do with it is way more likely to cause isses than the module by itself
    1 point
  13. Welcome @cgohio You have a typo in the URL in your question! Anyhow, I found https://www.gcbhs.com/ and the images aren't specified in PW, but are in a folder located at /site/templates/images/brandmarks/.
    1 point
  14. Key issue is to shed "regular cms thinking and habits" and get used to processwire decoupled way of doing things. Processwire having 0 limits can be confusing for a while. This issue has many posts in the forum. I recommend reading them. Also going through tutorials speeds up getting used to decoupled and the page concept. https://processwire.com/docs/tutorials/
    1 point
  15. @Macrura Sounds like something similar to the CraftCMS relations picker https://craftcms.com/features/relations in the video. Indeed, that would be good a feature for Processwire.
    1 point
  16. This job has been filled guys. Thanks for all the replies.
    1 point
  17. @Robin S Jonathan's concern regarding the stability of 'IDs' vs. 'text' was one of my concerns. After thinking about it, I was going to suggest if a hookable method was possible, so this makes me happy. I'll try it out today and report back!
    1 point
  18. My 16.04 is /var/www/ The 14.04 ran without a hitch. When I upgraded to 16 I had to change the following... Apache is 2.4.18 so the htaccess will need to be modified. Comments are in the file. There was also something specific to php 7, like mycrypt, exif, etc. not being installed. I don't recall offhand. I'll check and get back to you.
    1 point
  19. @ryan This might be a handy addition to the topic as well: https://gist.github.com/LostKobrakai/ddb11c64dcb0f1bf1c8eed4dd534a868 (prove-of-concept level) Chunked uploads would allow for file uploads beyond any php set limits even for files, which we obviously cannot shrink client side.
    1 point
  20. I started experimenting this morning. It's not all that difficult to get going. Proof-of-concept up and running already, so should have this functional on the core dev branch this week hopefully. (note: works for JPGs only)
    1 point
  21. My best guess is you need to add getVars: https://processwire.com/api/modules/markup-pager-nav/ (in other words read the fascinating manual )
    1 point
  22. This may be just my impression, but I think that this side of your modules, particularly FromBuilder and ProCache, would be worth exploring a bit further. I find myself extending both modules quite often for different client needs, and in my opinion third party extensions to these modules could bring in notable extra value. That, at least, is how it works for their WordPress counterparts. (Not saying that you should start mimicking Ninja Forms or Gravity Forms etc. but I do think that they have handled the extension thing pretty well.) Please don't. While Pro modules are better featured in other places, this is a good way for third party commercial module authors to get some extra visibility. That alone is a very good reason to keep this category around and even develop it further (Oh, and sorry if I misunderstood and you just meant that you might remove your own Pro modules from there. That's fine by me, though it'd be a shame; I like the idea of being able to quickly check out what the commercial module market for ProcessWire looks like.) Thanks for considering this. Perhaps you're referring mainly to new users bringing this up "out of the blue", but I for one tend to avoid bringing up topics that are, for an example, already listed on the roadmap. I'm probably not the only one who thinks like this, which might be one of the reasons why it doesn't come up that often
    1 point
  23. Most of our image/file features have been developed by the community rather than me, and I'm guessing this will follow a similar path. It doesn't seem to come up very often, but since you've mentioned it here maybe we'll have to bring more focus to it. I'll try to get a closer look this week to get a better idea of when we might be able to get more momentum going here. I do agree it would be a nice thing to have sooner rather than later. Also, since you quoted both 2016 and 2017 roadmap, it's important to note that this is a roadmap. It is a list of goals, it is not a contract of promises. We never expect to be able to accomplish all the goals, but feel it's important to have them nevertheless. Always good to aim for more rather than less. What doesn't get completed in one year still stays on the roadmap for the next year, unless it's determined it shouldn't be for some reason.
    1 point
  24. At our site we use both email and phone authorizations at frontend. To make life easier, I've developed HelperPhone pack that handles phone numbers. This pack includes following modules for ProcessWire CMS/CMF: FieldtypePhoneNumber: module that stores phone numbers InputfieldPhoneNumber: module that renders inputfield for phone numbers HelperPhone: module that loads PhoneNumber and PhoneNumberConst classes, and 'libphonenumber' namespace All these modules require included PW WireData-derived class PhoneNumber and PhoneNumberConst. PhoneNumber class is a thin wrapper over giggsey/libphonenumber-for-php, itself is port of Google's libphonenumber. PhoneNumberConst class stores constants, used by PhoneNumber class Usage: PhoneNumber class $phone = '8 (916) 318-07-29 ext 1234'; // input string could be in any phone-recognizable format $phoneNumber = new PhoneNumber($phone, 'RU'); // or wire('modules')->get('HelperPhone')->makePhoneNumber($phone, 'RU'); echo ($phoneNumber->isValidNumber() ? 'Yes':'No'); // Yes echo ($phoneNumber->isValidNumberForRegion($regionCode) ? 'Yes':'No'); // Yes echo $phoneNumber->getNumberTypeTitle(); // Mobile echo $phoneNumber->getCountryCode(); // 7 echo $phoneNumber->getRegionCode(); // RU echo $phoneNumber->getNationalNumber(); // 9163180729 echo $phoneNumber->getExtension(); // 1234 echo $phoneNumber->formatForCallingFrom('US') // 011 7 916 318-07-28 echo $phoneNumber->formatForCallingFrom('GE') // 00 7 916 318-07-28 For more methods and properties please refer to PhoneNumber and PhoneNumberConst source files. Need more? Check giggsey/libphonenumber-for-php and use it by accessing $phoneNumber->phoneNumber property - it is instance of \libphonenumber\PhoneNumber or null (if empty). Usage: field Note: on field creation, make sure that you've configured field settings Default region: assumed region if input phone number string is not in international format (starts with '+', etc) Enabled/disabled phone extentions: if disabled, phone extension will be removed on field save. Phone field settings in example below: default region code 'RU', phone extensions are enabled echo $page->phone; // +79163180729 // Note1: $page->phone stores instance of PhoneNumber and renders to string in E164 format. // Note2: E164 format does not include extension. echo $page->getFormatted('phone'); // +7 916 318-07-29 ext. 1234 echo $page->getUnformatted('phone'); // +79163180729 echo $page->phone->format(PhoneNumberConst::RFC3966); // tel:+7-916-318-07-29;ext=1234 echo $page->phone->getNationalNumber(); // 9163180729 Usage: PW selectors FieldtypePhoneNumber is instance of FieldtypeText. It stores phone numbers and extensions as string in E164 format with #extention (if provided by user and enabled in settings) E.g. in db it looks like this: '+79163180729#1234'. This makes it easy to query fields as any text field. echo $pages->find([ 'template' => 'my_temlate', 'phone^=' => '+79163180729', ]); // will echo page ids where phone starts with '+79163180729' Finally I've decided to put it here first and later to Modules directory (based on your feedbacks). GitHub: https://github.com/valieand/HelperPhone Enjoy
    1 point
  25. @Soma Hi, It would be cool if you could add this module the Directory too.
    1 point
  26. Hi! Look for Custom Editor JS Styles Set in the field configuration and enter a path for .js file. In this file you can define your custom styles like this: CKEDITOR.stylesSet.add('mystyles', [ // Block-level styles { name: 'Heading 1', element: 'h1'}, { name: 'Heading 2', element: 'h2'}, { name: 'Heading 3', element: 'h3'}, { name: 'Introduction', element: 'p', attributes: { 'class': 'introduction'} }, // Inline styles { name: 'Link button', element: 'a', attributes: { 'class': 'button' } }, { name: 'Highlight', element: 'span', attributes: { 'class': 'highlight' } }, // Object styles { name: 'Stretch', element: 'img', attributes: { 'class': 'stretch' } }, ]); Also make sure you have Styles toolbar item enabled.
    1 point
  27. Hi all Adding "rtl" Right to Left support to the template have no problem rather the website is RTL only or RTL and LTR. *with a lot of ways But when it comes to the CKEditor, If the website is RTL only it's no problem according to http://ckeditor.com/forums/CKEditor-3.x/No-BiDi-or-RTL-LTR-button-or-option-or-plugin-Drupal So in file: /wire/modules/Inputfield/InputfieldCKEditor/ckeditor-4.4.3/config.js In the CKEDITOR.editorConfig = function( config ) { I just add config.contentsLangDirection = 'rtl'; But what If I use multi language, English (ltr) and Arabic (rtl) ?!! I want the English body filed to show the editor ltr (default display) and the Arabic rtl (showing the content from Right to Left for easy editing) Its the same problem in TinyMCE here
    1 point
  28. Marc, when you are developing a site it's good to turn debug mode on. This will ensure that errors are sent to the screen, exceptions reported, etc. This can be found in /site/config.php. By default, it is false. You'll want to change it to true: $config->debug = true; Obviously you don't want this enabled for production sites, so remember to change it back to false for live/production sites. I don't see any problem with using var_dump, var_export, print_r, etc. so long as you are directing that output to where you can see it. Also avoid running these functions on PW objects as you may get into an infinite loop. Sometimes it can be difficult to track the output of these functions because PW performs a redirect after most POSTs. But if you use PW's built-in reporting functions, they will get queued between requests until they are output. Here are the relevant functions bellow. They will produce the messages that you see at the top of your screen in PW admin: $this->message("status message"); $this->message("status message that only appears in debug mode", Notice::debug); $this->error("error message"); $this->error("error message that only appears in debug mode", Notice::debug); If you are outside of a Wire derived object, you can call upon any API var to handle the notice for you. For example: wire('session')->message('status message'); wire('pages')->error('error message'); Note that these reporting functions above are for the admin (and related modules), and they don't do anything on the front-end of your site. How you choose to debug or report errors on the front-end is at your discretion. Personally, I keep debug mode on in development, and this puts PHP into E_ALL | E_STRICT error reporting mode... it reports everything possible. If I need to examine the value of something on the front-end, I'll do it the old fashioned way with just PHP. Though others may prefer to go further with their debugging tools. If you want to keep your own error log, here's how (anywhere in PW): $log = new FileLog($config->paths->logs . 'my-log.txt'); $log->save('whatever message you want'); You can direct it to store logs wherever you want, but I suggest using the PW logs dir as shown in the example above. This will make the log appear in /site/assets/logs/, and this directory is not web accessible for security.
    1 point
×
×
  • Create New...