Leaderboard


Popular Content

Showing content with the highest reputation on 10/11/2013 in all areas

  1. 4 points
    what.cliente ask.4 drupal or wordprass ? cliente ask 2 be able do this.or that or other not what cms u use cliente.want to do some thing web devaloper is 1 to say.what to do with web devaloper is expert on.tool not cliente unloss yur client.is also web devaloper love -willyc
  2. 3 points
    Hi Everyone, the last days i read a lot about the ongoing process of "modernizing" the admin theme, adding some features and getting some marketing buzz from people who aren't currently aware of processwires awesomeness due to the fact they didn't like the current admin theme. I must admit that at first was one of those "design oriented" guys and didn't dig deeper into the system because i didn't liked it's look & feel (or at least i thought it doesn't look "professional" enough to present it to our customers). Fortunately a colleague of mine finally managed to convice me giving pw a second try. After digging deeper i started to really like the concepts behind it. I tried different admin themes and git stuck with "ergo" which we currently are using on several pw instances. Although i weren't completely happy with it's look and feel on several details (but that's just me: i never heard one of our customers complaining ). The Idea of doing a theme by myself started to grow in my mind. After doing several layouts that "just beautified processwire to my taste" (i can post a "design evolution summary" if anyone is interested) i took a step back and started doing some more conceptual work and research. Specifically i thought about which "personas" are using processwire and for what reasons they are using it. Also i tried or looked at screenshots of some more "hyped" systems (ghost, anchor, craft...), asked out some (dev) co-workers and others who are content editors (which are the two main "groups" of personas imo) what parts of processwire could be done better or used in a more efficient way. The good (but not surprising) news is: There were almost no complaints about the current features. Long story short: With the "benchmark" in mind and some feedback i again started layouting. I rearranged some buttons, menus and tried to give processwire a more modern, clean and "up to date" look. But before i'm going to code all of this i wanted feedback from a broader audience so i can propably fix or correct things that you as everyday users aren't happy with. Here we go: I used the "w" of the processwire logo as a "picture mark" as it is pretty unique and can easily be recognized and remembered (You could also use this as a favicon). I kept using "processwire colors" for brand/product recognition (i know ryan stated people are complaing about them) but also tried to use them in a very minimalistic way so there is nothing that distracts editors from the content. I chose the menu to be positioned right for two reasons:1) Content first! The most part of work in processwire is editing and creating content. So why shouldn't content "rule" and be the first and most important thing (at least for LTR Readers)? 2) With the buttons and the menu both at the right side there is a "cluster of functionality" which makes it more efficient: Shorter ways for eye- and mouse movement, less things to "overlook" when actually editing content. The pages options within the tree are hidden (again: reduce visual complexity) into a dropdown with only the most commonly used one (edit) beeing shown (this should be configurable). The Font is the beautiful Fira from Mozilla <3 The messages are displayed "growl style" and can easily be closed by the user (or close themselves after a certain amount of time) I chose to use the content of ryans "new theme" example screenshots to make it easier comparing them in terms of visual hierachy. As you scroll, the buttons on the top will pin and scroll with you. This way it's always possible to save or view the page at any scroll position (the save/publish buttons are part of a module that's currently in devlopment here). The bar at the bottom will contain some shortcuts as well as less frequently used / system related stuff (i.e: user profile and logout). "Zen Mode" with closed menu. Just you and your content For those who like it bright: An example of an alternate version which is even more minimalistic. From my point of view there are some things still missing. I thought a lot about including a possibility to open the page tree from everywhere (as in Nico Knolls Dark Business and the ongoing Discussion in the Two column admin theme concept). I think this might be more effective to just test it from a ux perspective when actually coding the theme. My Idea is to build a static clickdummy and put it on github before actually releasing a "real" theme (with all the logic / js work to be done) to do some usability testing. Thanks for reading and i hope there will be some feedback! Best regards, Felix
  3. 2 points
    A quick tutorial how to create file downloads using pages You will be able to create a new page using template "PDF" (or any you setup), upload a pdf file. You then can select this page using page fields, or links in Wysiwyg. The url will be to the page and NOT the file itself. This will allow to keep a readable permanent unique url (as you define it), unlike /site/assets/files/1239/download-1.pdf, and you'll be able to update/replace the uploaded file without worring about its filename. Further more the file will also have an id, the one of the page where it lives. Clicking those links will download or open the file (when target="_blank") like it would be a real file on server with a path like /downloads/project/yourfile.pdf. You'll be also able to use the "view" action directly in the page list tree to view the file. Further more you'll be able to esaily track downloads simply by adding a counter integer field to the template and increase it every time the page is viewed. Since the file is basicly a page. This all works very well and requires only minimal setup, no modules and best of it it works in the same way for multi-language fields: Just create the language alternative fields like "pdf, pdf_de, pdf_es" and it will work without modifying any code! Still with me? ok PW setup Download folder: Create a template "folder" or "download-folder" with only a title needed. Create pages in the root like /downloads/project/ using this template. Setup the template for the pdf files 1. Create a new template in PW. Name it pdf 2. Goto template -> URLs tab and set the URL end with slash to no. (So we can have /path/myfile.pdf as the URL) 3. Create a new custom file field, name it pdf. Set its maximal count to 1 under -> Details tab. 4. Add the pdf field created to the pdf template. Easy. 5. Create a new "pdf" page using the pdf template under a download folder you created earlier. 6. Give it the title and in the name field add ".pdf" to the end (could also leave as is) Template PHP file for the pdf files 1. Create the template file pdf.php in your /site/templates folder 2. add the following code: <?php // pdf.php if($page->pdf){ wireSendFile($page->pdf->filename); } Done. To see the options you have with PW's wireSendFile() you can also overwrite defaults <?php // pdf.php if($page->pdf){ $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' => false, // string: filename you want the download to show on the user's computer, or blank to use existing. 'downloadFilename' => '', ); wireSendFile($page->pdf->filename, $options); } Simple and powerful isn't it? Try it out. Some thoughts advanced Create as many file types as you like. It might also be possible to use one "filedownload" template that isn't restricted to one field type but evaluate it when being output using $page->file->ext, or save the file extension to the page name after uploading using a hook. One last thing. You can add other meta fields or preview images to the template and use those to create lists or detail pages. It's all open to goodness. Again all without "coding" and third-party modules. Further more you can use the excellent TemplateDecorator to add icons per template and have a nice pdf icon for those pages. This as a base one could also easily create a simple admin page for mass uploading files in a simple manner, and create the pages for the files automaticly. ImagesManager work in the same way. Cheers
  4. 1 point
    Two days ago, an idea about a new admin theme came to my mind. Some hours later, I've crafted a first concept in Adobe Fireworks.... The look and feel of the admin is important Two months ago, I've introduced some teachers into ProcessWire. They were none-technically people. At the end, they knew how to use the admin panel to create content or update a gallery on their new page. However at some points, they got confused with parts of the admin theme -beside the problems with our concept on how to use fields and templates for creating content. I think one factor why Wordpress became so large, was the great Adminpanel. It works well and easy (as long as you have a blog and not a twenty-plugins-for-text-pages-site). Editing content on a daily basis is the main task of my customer. I've to take this aspect serious. Problems I wanted to solve Have the page tree always visible. If I do not click the right link, it will be closed after I've finished editing my site More visuals like icons. Simplify some workflows. Creating 3 or 4 pages can result in multiple unnecessary clicks. More focus on important links like the tabs. Guide my customer through some action. Help them to repeat simple tasks. The concept First: Nothing is perfect and its not possible to find one single solution for everything. This was just done in a couple of hours and it's only the first iteration. Quick action button Next to the ProcessWire logo is the quick "Quick Actions" button. It should be possible, to configure it like: "Create a new Page with Template X with page Y as a parent". Use it for skyscrapers, news or galleries. (Yes i know, the arrow is pointing upwards. This is wrong) Two column layout The page tree is always visible (as long as we are in the pages view). It can be navigated as the normal page-tree. If you click "edit" it will become highlighted. Every action that would take you to a new page, would be displayed in the other half of the monitor. Speaking of a "half monitor" - I think that most people use a screen resolution of atleast 1300px. The sidebar should take up to 1/3 of this. On smaller screens, it will become hidden by default or we just simply step back to single pages for each view. If the content is to long, the sidebar becomes scrollable. Page tree I like the Template Decorator made by mindplay.dk. It fits the concept well with black outline icons for every type of template. The same icons could be used in the Quick action menu. I'm note sure what to do with the "move" action. To Do list Think more about the behavior of the elements. Design the modules view. Rework the search and the top menu. Options to "brand" the panel for agencies while keeping the ProcessWire logos. What happens if we are on mobile (small screen) devices? Listen to your feedback.
  5. 1 point
    Lately there have been lots of people that are not enjoying the default admin theme, so we've been working on making something new. Not trying to solve all issues or add every new feature we'd like, but just trying to come up with something to have as an interim replacement for the default admin theme until we can afford the time to do something broader in scope (like Phillip Reiner's great admin theme design for example). So this theme doesn't necessarily break a lot of new ground, but hopefully has some of the improvements that people are looking for. Visually, the goal here was to find a lighter, more modern look and reduce the boxes-in-boxes feel of the current admin theme. I've opted to commit it to the dev branch because it requires the latest version of ProcessWire on the dev branch, and likely will continue to with updates. Meaning, I can't distribute this one as a 3rd party theme very easily. This is because I'm making core updates related to the admin theme at the same time. So if you want to help test this new theme, you'll need to grab the dev branch of ProcessWire. The new admin theme is in /site-default/templates-admin/. That means you'll see it as the default theme if you are installing a new copy of PW. But if upgrading an existing copy, you'll continue to get the old theme. If you want the new theme, then just copy the /site-default/templates-admin/ directory to your /site/templates-admin/ directory on your existing PW install. This would be in addition to replacing your /wire/ directory with the latest one from dev, as usual for PW upgrades. The existing default admin theme also remains in place in /wire/templates-admin/. So if you want to stick with the existing/stable admin theme, then just make sure you don't have a /site/templates-admin/ dir in place (unless you are using a 3rd party admin theme). This admin theme is probably not production ready, as it's not been tested in many browsers yet. I personally haven't yet tested it in anything but Chrome and Firefox in OS X. Please let me know if you experience issues in other browsers. I fully expect things won't be pretty in IE... but they never are. To start, this comes with 3 color schemes (though we'll be adding more too): Warm: Modern (similar to processwire.com site colors): Classic (similar to existing admin theme colors): To switch to one color theme or the other, specify a GET variable of 'colors' in any URL you are accessing in the admin: /processwire/?colors=warm /processwire/?colors=modern /processwire/?colors=classic To specify a default, edit your /site/config.php and set to one of the following: $config->adminThemeColors = 'warm'; $config->adminThemeColors = 'modern'; $config->adminThemeColors = 'classic'; We'll probably make this switchable in the user profile at some point, but that comes later. This theme also comes with some new features (most of which have been copied/inspired from the work of others here, whether in other admin themes, modules or designs): It now uses Font-Awesome icons rather than jQuery UI icons. We now only use jQuery UI icons for actual jQuery UI widgets. Note that asmSelect and our file/image inputfields are built as jQuery UI widgets, but I don't think anything else is. Basically, the majority of icons in the system are now Font-Awesome icons. You can associate Font Awesome icons with templates. When associated with a template, the icons will appear in the page list, in front of the page title. To use this, edit any template and go to the Advanced tab. In the "List of fields to show in admin page list", you can type in any Font Awesome icon name (in addition to the field names you could before). For example, in the Page List screenshots above, I have my "search" template configured with the value: "icon-search title". You can associate Font Awesome icons with fields. When associated with a field, the icon will appear at the beginning of the input. For example, I associated a coffee icon with my "title" field in the screenshot below. To do this, edit the field, click on the Advanced tab, and enter the icon name in the new field provided for it. The top navigation now supports simple dropdowns. A new "user" dropdown has also been added that contains profile and logout links. The main Pages screen contains an "add new..." button, that is itself a dropdown to a list of templates that are configured adequately for us to know where they would be added. To use this, you have to configure your template "family" settings. The search box is now ajax powered, though this was introduced a couple weeks ago in the existing admin theme too. The theme is responsive too, of course. This is all kind of preliminary and open to changes. I'm trying to keep the scope of the project fairly small since I don't have much time to work on it. But just wanted something to quiet the haters a bit for a little while, so that we can take our time on the bigger admin theme project for longer term. We'd appreciate your feedback if anyone has time to help test.
  6. 1 point
    As some of you might have noticed recently there has been a large "Frontend Performance Talks Offensive" (not only) by Google Engineers. Here are some high quality (regarding content) Videos which i enjoyed very much and thought you also might be interested in. A Rendering Performance Guide for Developers by Paul Lewis: Performance Tooling by Paul Irish Your browser is talking behind your back by Jake Archibald Gone In 60fps – Making A Site Jank-Free by Addy Osmani http://addyosmani.com/blog/making-a-site-jank-free/ Any suggestions for more interesting performance related stuff are welcome!
  7. 1 point
    Hi folks! Despite of ProcessWire being one hell of a cms, we and our clients' editors stumbled upon one issue that is at least annoying and sometimes a major drawback that could lead to customers favoring another software for their projects: In ProcessWire you cannot update an already public pages without simultanously modifing the page's public appearance. In short, we cannot save drafts, use editing copies ore any similar form of manipluating content that should not be published immediatly. This is quite a common use case if you like to - preview your changes before publishing (already addressed by the preview module]) - edit content in teams. - want to schedule publishing of updated content for a future date. - have to apply some kind of approval chain before publishing updates. - just want to quit working for today and continue tomorrow. Personally I think, this should possible a feature request for a future core release instead of a plugin module discussion. But plugin modules are all we have at hand for the time being. ### Reqirements ### So let's start collecting a list of requirements: - New logic is only needed when editing already public pages. No need to mess with the process of editing non-public pages. - Opening a public page for editing: - Instead of presenting the current public state of the page some kind of draft state has to be used to initialize the editing form. - A draft state euqlas the page's state at the time of the last publishing - potentially modifed by preceeding save-as-draft actions of an editor. - The draft state covers the sum of the field values of the page (existing of database content, files of image fields and maybe other forms of serialized data in case of more exotic custom field types being used). - Additionally pages consist of a set of "direct" properties, such as templates_id, parent_id, status, and sort being the most important. Whether this kind of data should or must be part of a draft state is still to be discussed. - Instead of one rather two different saving options must be offered to the editor: save changes and publish changes. - Save changes - When saving changes the public state of a page has to left untouched. - The contents of the editing form must be serialized in a different way updating or replacing any existing draft state or creating a new one if necessary. - Publish changes - This option equals the normal publishing action on public pages as it is implemented right now (due to the editing form being initialized with the current draft state instead of the page's public state). - Delete pages - When deleting a page (entirely) any existing draft state has to be discarded as well. - Preview pages - We need to provide a new preview option (in contrast to the view option) that allows rendering the page's draft state instead of the public page. - This function should be accessible from the editing view as well as from the page tree. There might and probably will be more requirements, but I think this list covers the most common aspects of a save-as-draft feature. As I'm writing this post, I already invested some time trying to implement a plugin module. Unsurprisingly I stumbled upon a bunch of obstacles leading to a halt and seeking help and opinions from the comunity. I'll try to describe the general strategies I came up with for implementing the draft state feature: ### Cloning the page ### My first attempt was to implement a cloning mechanism that duplcates a public page storing it in a hidden folder. The I tried hooking into ProcessPageEdit::execute() trying to replace the originl page object handdles by the module with my draft copy. This approach came to a halt due to the following problems: - The page object within ProcessPageEdit is stored within a protected property ($this->page) and referenced by all the methods of the module. Their is no direct way to manipualte that via a hook. I came up with some kind of dirty hack to circumvent that but this was far from a satisfying solution. - Some parts of the editing form still had to show details of the original page (e.g. the breadcrumps, the children, the state), so the page object used to initialize the editing form had to be some kind of mix of the public and the draft state of the page. - Most of this mixing state issues could be solved for the initializing. But when it comes to saving the draft state (not publishing changes) the need to divide the editing form's content in draft data and public data could not be solved (at least by me). ### Cloning field values ### The second approach was to not clone the entire page but all the page's fields to represent the draft state. This would solve the issues with special treatments for form values for status and template and therefor should be more elegant and "light-weight" in our efforts to mess with ProcessWire's default behaviour as less as possible. I tried hooking into Fieldtype::savePageField() and FieldtypeMulti::savePageField() providing special logic for storing field values in case of a public page being saved as draft. Additional the former mentioned hooking into ProcessPageEdit::execute() used to unserialize this draft field values and overwrite the page's public field contents. The main problem I encountered was that there are more than this two types of FieldtypeXYC::savePageField() implementations (Repeater, I'm looking at you!). Every custom Fieldtype module can and often will come up with its own implementation of serializing values which would have to all be hooked into seperatly (correct my if I'm wrong on this one) and handled accordingly rendering a generic Save-as-draft module useless. ### Cloning the form state ### So I tried a more direct approach, ignoring the existance of pages and fields completly, just looking at the editing form alone. A page's draft state can be represented by the pure form state (meaning the list of form elements and their values). So save-as-draft action could possibly be implemented by intercepting the svaing process of the ProcessPageEdit module, grabbing the form state and serializing it instead of the normal routine. Unfortunatly ProcessPageEdit::processSave() is a protected and therefor unhookable method. But even if that wwasn't the case, you still had to face a mix of the same problems that we encountered in the first two approaches (separating draft form values from public state values and the need of implementing different ways of serializing the form state for a multitude and mostly unknown list of different field types. Additionally you would have to duplicate a lot of code e.g. form validation and handling file uploads that has been covered deep in the guts of the ProcessPageEdit module. ### Starting the discussion ### So, this was a looong intro. And I already thank you if you're still with me. If you have any thoughts regarding - the core feature vs. module question - the list of requirements I came up with so far - my efforts in conecpting and implementing a plugin module - or the need of this kind feature in general drop me line (or two). Regards, Marco
  8. 1 point
    I feel like something like this should really just be an ultra minimal module. I don't generally believe its a good idea for software to give users superfluous ways of doing the same task. There should be one standard, clear, natural way of doing the task. Double click to edit is not an inherent thing. I recently handed off a site to a new client and while teaching her to edit the site I cringed as I saw that she was a "double clicker" (those people who think they need to double click weblinks to make them work), I forgot about this feature and throughout the teaching session had to tell her not to double click when she just wanted to open the pagetree and not edit that specific page. It was embarrassing and frustrating for both of us, if I were to give my honest opinion, it's a terrible feature and one that doesn't put the client first. You may have plenty of clients who wont make the mistake, but surely you will have some that do, and the default behavior of any piece of software needs to serve the lowest common denominator and be configured and tweaked from there for the power user.
  9. 1 point
    Thanks a lot ryan! I can't wait to hear more details. It's 2013. What do you think? Sure it will be responsive! For a "normal" (consumer) website i most certanly would have done a "mobile first" design. But for me processwire is a software that is used by "professionals" as part of their work (either developing or creating content). So i created it with "desktop first" usage in mind as most people are using some sort of desktop computer for their daily work. "Mobile optimization" will be done while actually coding the theme (though i did think of several things performance wise while designing... if you're interested in some really cool videos and links i'll open up a topic in "Dev Talk" as this is a little bit off topic). Thanks!
  10. 1 point
    Or maybe just make it require faster clicks. It is way more "slower" than usual double click on windows.
  11. 1 point
    Well said, this resonates with me and I suspect if you told me why these things are important to you I may share some of your values. I think this statement could be further developed into a very effective personal branding statement. Your branding statement will help connect to the types of clients you are looking for. http://www.entrepreneur.com/article/228631#ixzz2hNV6MBNo Haha, yep, I've done that.
  12. 1 point
    Greetings, Well, one of the ideas of using ProcessWire (in my mind) is to try and talk to people about the benefits of this system over "the big three." I actually think that's important, because ProcessWire is a terrific system and deserves to be used in place of the big three as much as possible. As we all know, there are many different categories of clients. There are clients who essentially ask us to develop their plan and use whatever system we want. They don't even care or know anything about different systems. They just know results. In those cases, ProcessWire is the easy path. There are clients who are already tied into another system (like Drupal or WordPress) but they let us know up front they are open to moving to a new and more flexible platform. These are also easy ProcessWire projects. Then there are those clients who are sort of "fishing around" and don't quite know what they want. They talk to us, and get pretty far in the discussion, then make decisions about a system. This is the category I was referring to earlier. To summarize: these are clients who are sort of learning in the process of discussing things with you. My problem is, I get excited about a project too early. Now, I totally agree with one of sshaw's comments above that I should streamline my early discussions so I don't invest too much time with these sorts of clients. Thanks, Matthew
  13. 1 point
    [quitamos]WillyC has a great point. [/quotamos] this what.all ladies say aboute me when they.got close
  14. 1 point
    Wow, looks great. Looking forward to the implementation.
  15. 1 point
    Beautiful work! I'm currently over my head on client work, but just wanted to quickly drop in and thank you for your great work and thinking here. I'll come back with a better reply (and catch up with the rest of the forums) once I get through this marathon work week. I've been working on admin theme stuff a lot lately (before this week at least), so it's very fresh on the mind and I'd be happy to collaborate on the back-end side too.
  16. 1 point
    PW is defintely more a CMF than a CMS. As a marketing strategy it is difficult to say which way is better. For technical people I have explained that PW is Django of PHP world.
  17. 1 point
    Say, I need a special content which can only be viewed by people who know a password but don't have to be registered with the site? And only on this special content type the users knowing the password are allowed to answer comments of other users? This is probably easy enough to do with a cookie or session, but it's not supported out of the box. You would create a login page, which is just a basic page. Then you do most of the work in the template file using traditional php. You can add a password input field and set the cooke if the user logs in successfully. Then on your templates for the protected content, you can check to see if the cookie exists and allow comments if it does. You can also make this into a module, but initially you won't know how to do so. 1) What literature is to be had on Processwire which can bring me up to speed in a very short time? Limited documentation compared to Drupal. It will take 2-3 months for you to get a handle on PW if you understand oop programming, typical patterns/paradigms and frameworks. Compared to Drupal which is really a three year learning curve, that's not bad. If you come from Drupal or WP though, those will help you a little. If you use php frameworks and/or jquery, PW is as easy as it gets. 2) How big and friendly is the community. (The German Drupal community is rude and and acting aloof, the English-speaking community is very polite and helpful especially the maintainer of the superfish module)? Small, but friendly. 3) Are there responsive Processwire themes and which ones are the most modification-friendly? there are no themes for PW, however I'll be releasing a theme framework soon. All of my themes are responsive html5. Super modification friendly. So much easier than WP even. 4) What is the nearest equivalent to the Drupal module "Views"? templates. much easier and faster. 5) Is there a module like "Webform" for Drupal? yes, it's $40 USD I think. 6) And: within the European Union ("EU") - bavaria is unfortunately part of the EU (and Germany for that matter) - there is an "EU Cookie Guideline". When this guideline raised its ugly head there were about four Drupal modules I could choose from which addressed said EU red tape. How are things handled with Processwire if this or other bureaucratic obstacles crop up suddenly? This is specific to your needs, so I don't think PW is going to address this. You have full control to do what you want with PW though. It doesn't get in your way. 7) This WYSIWYG editor I'm using right now is CKEditor or am I wrong? I think this is tinymce, however there's a module for cke and it works quite nicely with some advantages over tiny in my opinion. 8) How about internationalization and translations with Processwire? As good as any. Translations work nicely, but many third party modules aren't translatable (you can fix this easily inside the module and submit your work back to the owner).
  18. 1 point
    Greetings, This is a sore topic because -- for some crazy reason -- two potential jobs in the past week slipped away from me: one to Drupal and one to WordPress. In both cases, the client was ready to move forward and I had the scheme for the sites laid out. Then they got ideas about the "other" CMSs and just did not believe that sites could be created more rapidly and better in ProcessWire, with more design and administrative customization now and in the future, and with better security. The sheer bulk of Drupal and WordPress became their overpowering argument. It hurts... I think this question becomes easier for those of us in the following two scenarios: 1. You already have a successful independent career as a developer and your portfolio convinces clients to use your system of choice 2. You work for an agency and have successfully convinced your bosses to use ProcessWire instead of one of the "other" CMSs For those of us who are in the middle (you're an independent, still building your clientele) it can be very frustrating to lose jobs to systems that you just know are inferior. I'm not going back to Joomla/Drupal/WordPress. But I'm not sure what the solution is for this dilemma. As a side-note: the more I use ProcessWire, the more I am convinced that the comparison we should promote is NOT ProcessWire vs "The Big Three." I think the comparison we need to make is ProcessWire vs PHP frameworks like CodeIgniter, Cake, and Yii. Of course, this would mean re-structuring the messages from the site and what gets presented first (API or admin back end). This is probably a separate discussion, which I would really like to have! Thanks, Matthew
  19. 1 point
    I've pushed several updates consistent with the feedback above. This includes going a little more minimal on some things, converting absolutes to floats, making the lines more visible, and numerous other updates. I also added another color theme "futura", which is based on Nikola's Futura Remixed. With regard to typography, I'm going against my own preferences and making the type bigger, bolder (in Classic and Modern), and increasing the line height. These changes make it less usable to me personally, but my conclusion from previous feedback was that others may prefer bigger/bolder, more height, more room, etc... so just trying to find a balance. After all, the point here is to have a theme that appears to a broader group, rather than one that maximizes usability at scale. Or at least to find a balance. Regarding there being some redundancy or things that need cleaning in the CSS–I'm leaving a lot of extra stuff in there since I change my mind a lot. I'm not going to fully clean and remove redundancies until it's final. So please don't look for perfection here, this is a work in progress. I'm not going to vacuum this place until the work is done. Regarding use of Arial as the typeface: I tried switching to OpenSans, but there was just too much personality to it that I thought it was influencing the tone too much, and ultimately too distracting. If you guys can think of any other free, fairly neutral webfont typefaces worth trying, please let me know. I would love to find a better alternative to Arial. Edit: Almost forgot, here's the screenshots of the updates. ./?colors=classic ./?colors=modern ./?colors=futura ./?colors=warm
  20. 1 point
    2.4 will be released once the dev branch source has sat for a week or so without any necessary fixes or major additions (meaning, it's reached a stable state). I think that's probably soon, but don't want to promise any dates since I'm actively working on the code almost every day.
  21. 1 point
    Put this in your config.php: setlocale(LC_ALL, 'Polish_Poland'); You could try changing this: "<div class='date'>{$e->date}</div>". to: "<div class='date'>" . strftime("%e %B %Y", $e->getUnformatted("date")) . "</div>". I'm not a programmer so this could be totally wrong.
  22. 1 point
    Found it, could be useful for others people: Apparently Media Temple Grid has PHP by default as FastCGI and this doesn't go well with PW. Luckily you can still change it to CGI, see attach Regards Sylvio
  23. 1 point
    They shouldn't be compressed. Regarding the 1-line issue, we can correct this on PHP 5.4 and newer as json_encode() now has a JSON_PRETTY_PRINT option, which makes it output the JSON in a human readable way (and I'm assuming a much easier-to-version way). I'm going to add a check for PHP 5.4 so that we can start taking advantage of this now.
  24. 1 point
    At least in ProcessWire, the tree is far more scalable than a linear bucket system like in EE. If it helps to conceptualize, think of ProcessWire as having a tree of buckets. This is the natural way the web works. If a single-level linear bucket system suits your needs, then you can do this in ProcessWire. But there's a good chance you can do much better. So I would argue that your statement about buckets vs. trees is backwards. In terms of scalability, a tree will take you much farther. But it does require that each branch in that tree have the ability to function as an unlimited bucket. This is exactly what ProcessWire does. Also consider that websites have hierarchy by nature, need and design. That hierarchy is extremely useful and powerful, and should be embraced. Websites lacking hierarchy would be limited, for obvious reasons. When working with a linear bucket system, you are always mapping a hierarchal system to buckets. This has always struck me as completely unnecessary, complicated and unfortunate. This mapping and conversion is ultimately a side effect of having to reduce a powerful system of tree hierarchy (upon which the web is based) to a less powerful bucket system. But if the system embraces the natural hierarchy of the web, then no mapping or conversion is necessary. You are working with the tree either way. The question is whether the system is embracing and using it (like ProcessWire), or mapping it to a more limited system of linear buckets. I don't have enough experience with MODX to know what the "resource tree shortcoming is", but am guessing it's something to do with pagination that others have mentioned before? I know that MODX has a reputation for being quite scalable, so would guess that they just have a different approach to managing that scale. But once you have worked with trees, and really experienced the benefits, it's very difficult to go back to buckets, IMO. The words "tree" and "shortcoming" simply do not go together. As for keeping more than one CMS in your toolbox, I think that's always a good idea. It sounds like MODX and ProcessWire have common ground in terms of philosophy, and these two would be good to have in your toolbox. I don't think I would bother with keeping a bucket-based system in your toolbox, except for perhaps WordPress, which can be handy in the right situations (like one-off blogs when client has very limited budget). ProcessWire is pretty much infinitely scalable, within the boundaries of a server, SQL database and file system. As scale increases, you do have to practice care in how you use the API. ProcessWire gives you a lot of power, and will fill up your memory if you tell it to. So you have to use common sense when using the API at the large scale. For example, an API call like $page->children(); might be referring to a million pages. Do you really want to load and display links to a million pages at once? (probably not). Does the server have enough RAM to keep a million pages in memory at once? (not likely). So you accommodate scale by specifying limits and using pagination, like $page->children("limit=50"); This is something you don't necessarily have to consider at the smaller scale. But I think it's a good practice to design and develop every site as if it could grow infinitely. Do you need to learn PHP? Not any more than you would need to learn the {tags} from another system, like EE. The time investment and scope of what you'd have to learn would be about the same, maybe even less with ProcessWire. In fact, you can do almost anything in ProcessWire by simply learning how to use just two API variables: $page and $pages, and knowing what a PageArray is. There are a few bonuses you get from learning PHP vs. a tag system though: Whatever you learn about PHP is something you can take with you, beyond ProcessWire. The more you learn about PHP, the more you can do, both inside and outside ProcessWire. Meaning, the environment can grow with you, when and if you want it to. Whereas, at some point, you'll start hitting your head on the ceiling in a {tag} environment. ProcessWire's API is identical regardless of context. You can be in a template file, command line script, plugin/module, etc., and everything works the same. In a {tag} environment, if you want to grow and learn plugin/module development, you'll be starting from scratch. In ProcessWire, everything you learn applies throughout the system in any context. It's only a small step to go from building templates to building modules. In {tag} systems, it's a canyon. In fairness, while you don't need to know much about PHP to effectively use ProcessWire, you may indeed need to learn more PHP to accomplish some of the things you've set out to do: paid membership and access, member signup forms, etc. ProcessWire is a tool more than a turn-key solution for these particular needs. While they aren't difficult to accomplish, you might find yourself doing more on the code side than you would with a system that has turn-key solutions for membership sites. If your project budget/timeline doesn't give you the room to learn and build these things, you would want to investigate more ready-to-use solutions for these. But I think you would do well to make friends with and use ProcessWire either way.
  25. 1 point
    I would actually separate out each Vendor and each invidivual Product to be under their own tree like: /vendors/vendorname/ /products/product-1/ You then just use a Page fieldtype to link products to relevant vendors: http://processwire.com/videos/page-fieldtype/ and then use code on the product name something like this to pull the vendor into the product page: <?php $productvendors = $pages->find("template=vendors, id=$page->vendors"); // Assuming you could have more than one vendor per product $productvendor = $pages->find("template=vendors, id=" . $page->vendors->first()); // Or just one vendor You can also do it the other way to view a vendor page and list all products they sell: <?php $vendorproducts = $pages->find("template=products, vendor=$page"); // Assumes your Page field is called vendor
  • From Twitter

    • Get notified of updates

    • ProcessWire Weekly #219 - July 21 2018
      In the 219th issue of ProcessWire Weekly we'll take a closer look at the built-in Two Factor Authentication support feature that Ryan has been working on, introduce a couple of new third party modules, and showcase a really nice new site of the week. Read on! / Subscribe / More at weekly.pw