Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/07/2014 in all areas

  1. We've just released a small website as part of a complete "corporate launch" (Logo/CD, Print, Online...) for a newly founded german change management consulting company. http://www.priotas.de/ Modules used: - Thumbnails - SEO - TemplateDataProviders - TemplateTwigReplace Feedback is as always much appreciated.
    13 points
  2. It is a good question and one that gets asked rather a lot, one way or another. It is all too easy to write down long lists of clever functionality, or to write crafted documentation and tutorials, or to put together neat little sales lines that package it up in an easy to understand bundle. But, ultimately, any tool is defined best by the type of people who use it and by the community that grows around it. Well, today I realised the perfect answer to my question. THIS is ProcessWire: Thanks Diogo - Christmas landed early in my post box this year!
    7 points
  3. Three days at Beyond Tellerand made @marcus and me spawn some great ideas for this. One of which is that we will maintain a text-based repo of recipes, so that they are decoupled of any database, are properly version controlled and anyone with a GitHub account can contribute easily. This may be great opportunity for those of you who have not yet been using something like git to finally dive into it. I wrote an importer module, which already works pretty well. The rough structure is decided upon as well. Let's get it on! PS: we also met nico one day, what a very nice fella he is .. I had too much to drink that night though
    7 points
  4. A little more civility, respect of others beliefs and an actual ability work in a collaborative environment would make these discussions productive.
    6 points
  5. Suppose I better drink some before I debug this template on my next ProcessWire Website...
    6 points
  6. So, I am nearing the completion of this site and I suddenly notice that just beneath my navbar a line of text has appeared. What? I didn't put that there! How long has that been happening? Well, I have been messing with a couple of functions, so that must be it. I delete them, but it is still there. Oh. I delete more off the page. Still there. I look at the source. Whatever this is it has effectively chopped my <head> in two - half of it is now sitting inside the body tags. I look at the head.inc and delete quite a lot of it. Still there. The text actually sort of relates to some of the info on the page. So I delete a couple of fields from my template-file. Still there. I turn to another page - same problem, And another. Same problem. Try one with a different template. Same problem. Then another one. And that one hasn't got it. Huh? It is the same template I started with! Okay, if in doubt, read the text. It dawns on me that the text is a list of child pages - the last one I tried does not have children. So, where on earth is it coming from? On a hunch, I open my functions file which contains a lot of the logic for this complicated site and search for "children" The search takes me straight down to the bottom of the page to three little lines all on their own and not in a function: foreach($page->children as $child){ echo $child->title; } What are those doing there? Then I remember. https://processwire.com/talk/topic/8176-end-user-usability/?p=79356 Earlier today I posted a comment on the forum and wanted to add a little bit of code. To make sure I made no mistakes, I quickly typed it on whatever I had open in Sublime text, copied it off and promptly forgot all about it. It has just cost me an hour of cursing. Very, Very, Very, Very Silly And a few stupids too!
    4 points
  7. Let's use names of CMS systems Drupal Wordpress eZ Publish DotNetNuke eZ Publish Mambo Pimcore
    4 points
  8. Hi Dazzyweb As I said, there is no problem with creating functionality as modules or even profiles built on the wire base - as long as they are properly done, secure and reliable. But I do think something that creates quite so much plug-n-play functionality needs to be a completely separate project. Something like that will take a huge amount of maintenance and support and ProcessWire is not set up to handle that. I was part of the Liferay bug squad at one point (just looking at the usability of it). There was a pile of us trying (and succeeding) in breaking beta versions and the Liferay team only just managed to keep up with us - and they have a decent sized, fully employed developer staff. What I think is wrong with these conversations that keep coming up is that rather than someone proposing a module that does what they want and either building it or getting people around them to build it, they leap in and demand that the ProcessWire developers should drop what they are doing and change ProcessWire to suit their needs. There is a big difference between threads that start "Why doesn't PW do this?" and threads that start, "I am developing a new module for PW...." The whole point of ProcessWire is that a developer can add their own functionality and do not have to wait for Ryan to do it for them. There are loads of modules out there that devs have created for particular work projects, but don't get released to anyone else because they are client-specific. And for those of us who do not have that skill, well I just do things the long way round....
    4 points
  9. lisandi: would you mind opening a new thread somewhere, probably in the modules area, about this particular website builder tool you've mentioned a few times.. and/or any other specific ideas you've got? It seems that you've got ideas about specific tools you'd like to see integrated (or built) with ProcessWire, and by no means do we want to stand in your way, but I'm afraid that current thread is simply way too broad and way too long-winded to result in any real, solid, or useful outcome. As someone who should know a little bit about how this community works, I'd suggest that you try to keep those threads to the point; don't wander into philosophical stuff, just explain what you're planning to do and what you're expecting (hoping) from others. It looks like you've got a very interesting project (or couple of them, perhaps) in your mind, and you'll probably find a few like-minded folks around here if you just focus on one thing at a time By the way, earlier when I said that I can't showcase our non-public client projects, I really meant that. Our clients trust us to keep their private matters private, and we would never do anything that has even the slightest chance of compromising that trust. In fact, generally speaking we always ask for a permission before showcasing any client work, public or not. I hope you understand this, but even if you don't, that's how it goes. Just wanted to make this clear
    3 points
  10. @lisandi I wish I could give a like to some parts of your post and a dislike to other parts. I do like your enthusiasm and energy and honesty. You are not scared to share your opinions even if others don't agree and that can be a good thing even if it rocks the boat a bit. Hell I have done that a few times. I know that some of the answers here might seem a bit stick in the mud . I get it, really. I feel the same frustration sometimes but best to keep your posts civil. Everyone has their own ways of expression and perception and idea of where they would like Processwire to go. The guys and girls in this community are some of the best you will find. We need to respect what Joss and the others have already given to bring Processwire to where it is now. I would say that the best way to express what you want is to get building then show us.
    3 points
  11. The big rule for processwire is really simple. ProcessWire, as it is, allows anyone like you to go and develop any functionality you wish - including a templating system. The Blog Module is a lovely example of this. However, these are applications using processwire and should not be part of processwire itself for several reasons: Firstly, it weakens the brand by being too many things all at once - ProcessWire is a Content Management Framework, first and foremost, and that is it's strength. Burying that powerful brand value behind a wall of plug and play would be bad marketing. Secondly, everything you suggest takes a vast amount of maintenance. Who maintains all that? The ProcessWire developers, the true, full time ones, certainly don't have the time. (Do you, Ryan) And when it comes to a templating system there is a really good reason why ProcessWire doesn't have one - it doesn't need one. It already comes with the best templating system on the planet - html + php. What else do you need? My list of child pages in ProcessWire: foreach($page->children as $child){ echo $child->title; } That is not complicated even for a complete non-coder. I don't understand this need to add yet another layer of complexity on top. Templates require everyone to use the same field names or to pre format html markup at some earlier level so you can do things like render out the entire contents of a page without worrying what fields are in there. But that suddenly becomes web design with your hands tied behind your back. The entire reason why the vast majority of people are here using processwire is because they left systems like WordPress that restricted their design needs or over complicated them. There is nothing wrong with creating a system like Wordpress or Joomla based on ProcessWire. But it should be a separate project, separately maintained and not done in anyway that undermines the original product. Here is a good example of what I mean by that. I still have a couple of WordPress and Joomla sites that are yet to be migrated and last night I received a security alert about Bullet Proof security that has had to be patched because it was riddled with security holes. That plugin has been downloaded over a million times, but though it is independent of WordPress, for me it signalled yet another reason why I will no longer use Wordpress - the faults of that plugin, though corrected, have undermined the good name of wordpress. Wordpress is so huge that it can survive that. Could a relatively tiny project like ProcessWire survive the reputation hit in the same way? So, the bottom line is that ProcessWire development has been governed by fulfilling the needs of developers who require the huge flexibility not offered by systems layered with templating systems and presentation plugins and also by keeping its scope manageable by the development "team" so that it remains fast, secure and solid. (by the way, half the reason it is so fast is that it does not have all that extra presentational layers) As I said, there is nothing wrong with modules that add functionality, but they need to be add ons and NOT redefine ProcessWire itself.
    3 points
  12. ... got lost in crone Here is another one ... cronjob for database backup. All Informations here: github: https://github.com/kixe/CronjobDatabaseBackup PW Modules: http://modules.processwire.com/modules/cronjob-database-backup/
    2 points
  13. FieldtypePageWithDate & InputfieldPageWithDate Module for ProcessWire - Page Reference with Date Field - Field that stores one or more references to ProcessWire pages Modified version of the FieldtypePage module in ProcessWire with extra datetime field containing the date a page was added to the inputfield. Github URL Link: FieldtypePageWithDate To install Copy to /site/modules/ and go to Admin > Modules > Check for new modules. Requirement Requires: InputfieldPageWithDate (will be installed automaticly) Tested on ProcessWire 2.5.6 dev Setup in back-end install both modules:FieldtypePageWithDate InputfieldPageWithDate create a new field in ProcessWire and give it a nameeg. myfriends as type choose PageWithDate choose the right dereference for your needs (all 3 modes work fine with this field)Multiple pages (PageArray) (in this example we are using this) Single page (Page) or boolean false when none selected Single page (Page) or empty page (NullPage) when none selected assign a selector to the field, in this example we will use users Template of selectable page(s) (select the user template) choose a label field, since we are using users set it to name Label Field name set an input field type, depending if you are using dereference of multiple or a single pagefor this example we are using AsmSelect save the field and assign it to a template of choice Add some users/friends to the field by editing a page with this template Usage in front-end In you template you can acces the field as you usualy do with any FieldtypePage. In addition to this the new parameter "assigned" is available Multiple pages if (count($page->myfriends)) { foreach($page->myfriends as $friend) { echo "id: ".$friend->id."<br>"; echo "name: ".$friend->name."<br>"; echo "assigned on: ".$friend->assigned."<br><br>"; } } This will output something like: id: 1031 name: johndoe assigned on: 2014-10-31 14:22:02 id: 1032 name: janedoe assigned on: 2013-04-15 23:16:38 Note: To use your own data/time formatting set $friend->of(false); to get a unix timestamp from the database Single page echo "id: ".$page->myfriends->id."<br>"; echo "name: ".$page->myfriends->name."<br>"; echo "assigned on: ".$page->myfriends->assigned."<br>";This will output something like: id: 1031 name: johndoe assigned on: 2014-10-31 14:22:02 Note: To use your own data/time formatting set $page->myfriends->of(false); to get a unix timestamp from the database Edited: removed extra date() formatting since value is formatted by default. Set assigned datetime manuallyYou can set datetime manually by assigning it to the page you add $friend = $users->get('johndoe'); $friend->assigned = "2012-01-01 12:12:12"; $page->myfriends->add($friend); $page->of(false); $page->save(); Edited: Added information on manually setting the assigned to a datetime value. (if you previously installed this module you need to update atleast the FieldtypePageWithDate.module file)
    2 points
  14. Was a really nice evening
    2 points
  15. Here's some info from namecheap on SHA-2. After listening to the excellent podcast suggested by Steve and then reading the above namecheap page I think each time I go to buy a certificate I am going to make a cup of tea instead, that way I don't need to worry what type to get. And I get more tea. So that's a win-win.
    2 points
  16. Thank you for the suggestion! Making a new textarea fixed my issue! And during the creation... I think I found what caused the issue, I will try to explain it in points: When you've created a textarea field and its input type is still 'Textarea', you have different settings available. (http://i.imgur.com/M27haJB.png) One of these settings is 'Strip tags', which removes all HTML tags. (http://i.imgur.com/oQO9YCU.png) When you check the setting and switch to CKEditor, the 'Strip tags' setting is still enabled in the background, but you can no longer see or edit the setting. That's what caused the problem for me. Sounds silly and frankly, even I don't know why I decided to enable it. Hi Kongondo, thank you for moving my topic and for your concern. Could you please delete the double post that happened due to the move of my post? Thank you in advance. PS: I love your Blog module! It is awesome in many ways and your work is greatly appreciated!
    2 points
  17. Andy, you're pretty energetic. What if you start to mockup the things you want. Just describe every template and every field and every relationship and how it should be presented. After that build the whole site with static HTML. If done all steps, you've a fundament from where development can start.
    2 points
  18. I don't think a website-builder-tool for frontend is the way to go for processwire. Processwire is about structuring your data, making connections between that data and query that with the API. This is the work done in processwire for a developer or designer, to enable his clients (or himself) being able to collect the data and have it output in a proper way for a website or something else. If you use a builder for frontend-editing, the end-user has control of the formatting and arranging of the data, which sometimes is not desired. In my opinion, a CMS has to make constraints for the data to ensure the integrity and applicability, the PW-backend is very useful for this. E.g. a user wants to have three featured items on the homepage, you can easily do this with a website-builder as well using three equal-width blocks. But what if the user wants four or more items? If the developer was clever he thought about this in advance and made a slider if more items are added. (You can argue that you maybe can also add a slider element in website-builder... well, then this is example is not the best, but i hope you get the point) In conclusion, the developer of the website makes decisions for the end-user that his data is presented in the way the developer has supposed it to be. He is the expert in making the website usable for the visitor, the end-user is expert in his business and over his data. Btw. don't get me wrong, i like some of your ideas and i think themes should being brought into PW in any way former or later.
    2 points
  19. Just committed an update to the FormSaveReminder as it's an essential tool in your bag Changelog 1.0.4 - refactored code a bunch to simplify things - added support for CKeditor, regular and inline mode - made alert message translatable If you find any issues, please post in this thread or better open an issue on github . Next: - Look into PageTable, and why it's not triggering on changes. - if you find anything or want to help improve the module just shout For module developers To make sure your custom Inputfield works with FormSaveReminder, you'd have to make sure the input is triggering a change event. Sometimes this isn't the case if you simply change a value through js. You can after chaning a value use the $(element).trigger("change") to make sure FormSaveReminder will be able to detect a change. Thanks
    2 points
  20. Hi Christophe Always best to use the latest version, however, nothing need converting. When developing with a framework, I strongly suggest you start with the blank profile so you are not fighting against any existing systems. Then, add the framework in exactly the same way as you would for a static site (so, using the authors recommendations), but in the /site/templates folder. Next, I would suggest that using your home.php template you create a complete html page from <html> to </html>, just as suggested by the framework authors. Don't worry about anything ProcessWire, just put straight html in there. Note; see my tutorial about referencing css and javascript - this is the only "conversion" you need. Once that is all up and running, then you can split it up however you want to proceed. If this is all new to you, I suggest you just go for greating a head and foot and include them into the top and tail of your template. You will soon work out your own system. By the way, if with Foundation you use the scss files and work in SASS, then Prepros is a very good, all in one windows/mac solution which works well - you wont need to install ruby or compass, it is all included.
    2 points
  21. This module allows the page name to change when the title is edited. Modules directory: http://modules.processwire.com/modules/page-rename-options/ Github: https://github.com/adrianbj/PageRenameOptions I'd love to think that this module was not necessary for me but, especially during development, I find that page titles often change and I'd really rather have the names/urls match the title. I don't think you can expect clients to remember to change the name when they change the title, or even if they do, they still have to get it right which can be a challenge with a long article names with characters not allowed in page names. With none of the config settings checked, the default behavior is to have the page name always match changes to the page title, but allow the user to manually edit if they want. The options allow you to protect initial differences (changes you may have made as a user with an exempt role), completely disable manual changes, or protect manual name changes from subsequent changes to the title while editing. My preferred settings are to set the exempt role as superuser, and check "Initial Differences Protected" and "Prevent Manual Changes". CONFIG SETTINGS Exempt Roles The selected roles will not be subject to any of the rules below. The name will change automatically with the title, but they will be able to manually edit the page name as desired. Excluded Pages Pages that are excluded from the actions of this module. Changing the titles of selected pages will behave as though this module is not installed. For multi-language sites it is recommended to select the site's homepage. Initial Differences Protected If checked, further changes to the name (to match a changing title) will not happen if the name is already different from the title (evaluated on page edit initial load) Prevent Manual Changes If checked, it won't be possible to manually edit the name. If checked, this will disable the "Live Changes Protected" setting since it won't be possible to make any manual changes. Live Changes Protected If checked, further changes to the name (to match a changing title) will not happen if the name field was manually changed at any time during the current page edit. Please test the behavior of each setting thoroughly so you understand what each one does! Please let me know if you have any further requirements around permissions / role access to the module's functionality.
    1 point
  22. I've created a new Textformatter in the last couple of days: TextformatterSrcset will add a srcset attribute to all your images inside a Textarea. Depending on your configuration, it will create all sizes for the images, make a double-sized one for HiDPI/Retina devices and you can even create a low-quality placeholder. Read more at Github and make sure that you read the examples. It was build to work perfect with the two scripts from Alexander Farkas, respimage and Lazysizes. Do yourself a favor and try them out. They don't require jQuery, they have wonderful fallback and are fast and easy to use. More information and downloads on our Github repo. This module is currently quite stable and tested against multiple configuration variations. It works Some code improvements are needed, so use with care. Feel free to ask any questions you might have.
    1 point
  23. I'd like to see a caching API added to Page objects. This would differ from WireCache, in that this would enable caching in a Page-specific context, which would make it possible to provide some meaningful options for (among others) cache expiration in a Page-context. The API might be something like a PageCache class, which is attached to Page objects as e.g. $page->cache. It would work much like WireCache, but would write cache entries with the Page ID attached to each entry, allowing some new options for cache expiration: Expires when the Page object is deleted Expires when the Page object is changed Expires when the Page object, or a Page in it's parent path, is changed When, for example, you have a page/template that aggregates content from another page (fetching content server-side), or when your template needs to perform expensive calculations or database queries to produce the page content, the fetched/generated content could be written as cache entries that lives forever (until the Page object is deleted) or until the next change to that Page, or a parent Page. Thoughts?
    1 point
  24. Would it be possible to add a Lister filter for text fields: "Does Not Contain"? I'm looking for the opposite of "Contains Text" shown below. We have "Not Equals", but no negative operator for partial string matches. Is this omitted because of performance concerns? Thanks!
    1 point
  25. Ask a non-techie if they want to see how you monitor your crontabs and I'm guessing you'll get the same reaction to asking them if they want to know more about the invitation to "fork me on github". They both sound scary. But I finally 'got' why this service https://deadmanssnitch.com/faq exists after setting up a crontab. Anyway, I've no affiliation with these guys but they seem very friendly and if you're into proactive monitoring then it might be something you want now or later, so I thought I'd post. Enjoy
    1 point
  26. Horst, first, and not connected, THANK YOU for your SMTP module. I am loving the much improved way mail is delivered over SMTP versus PHP Mail function. 1. I think the idea is that you see no email, all is silent—unless your cron fails. Only if it fails will you get an email (what you want). 2. Hehe Though serious point is just that without Snitch if cron works then all good, no emails, if it fails then you don't know. With Snitch if cron works then all good, no emails, if it fails then, unless Snitch has also failed, you get an email I am sure clever people can add their own scripts for monitoring, but DMS seems great for lots of cases, not least of which people like me who are not very clever at server scripts
    1 point
  27. @alan: thanks for sharing, - but to be fair I don't really get for what this should be good? 1) I can send _me_ an email at the end of a cronjob (or a windows schedule task). Why should I notify unknown people? 2) What is if my cron has run perfectly until its end, but the snicth-service is unavailable? Do I need a snatch-service too, (what monitors the snitch-service)?
    1 point
  28. Lisandi, i think you are mixing things up... A end-user in my opinion is someone who logs in the backend, changes text, images, data, inserts pages, moves them and deletes them. He doesn't have to care which modules are making his pretty website, he's just filling in the forms with his data. Maybe he updates modules or the core, but won't install any modules himself. A website-developer cares about how the data is brought together to form a decent website. He decides which modules he is integrating or he has to tailor for the specific needs for his client. Sometimes these two fall together (nearly everyone can install WordPress) and i think this is the point you are trying argue about. For end-users, who like to dive more into the systems, the steep in Processwire is still higher than for Drumlapress. If more such people are attracted to Processwire, the community will grow and also more people will actually develop modules for this system. The problem with the apps you mentioned is that maintaining, debugging, updating und error-checking is very time-consuming and most people don't make many with modules, but with the websites they build. If a core-update is breaking a module it is most likely not the fault of the developer of the module, but for changes in the API or the way ProcessWire does certain things. And before building big monolithic apps we should focus on building smart parts of software, which can than be glued together and expanded on the client/end-user wishes. Take a forum for example, there is the discussion module from apeisa which mimicks the essence of a forum, but is not such a beast like phpBB oder IP.Board, the same goes for e-commerce, blog, ... Sure, it would be great to have e.g. a working prebuilt e-commerce just after installing. Many man-years of developing stand behind such applications like Magento. I don't see the infrastructure for this at the moment for ProcessWire. Behind TYPO3 or Drupal for example stand firms which employ core developers, so they can concentrate on this and not on making money with actually building websites. For really end-user usability i would now go for different profiles, that are choosable at install. See my earlier post from me on this (also a great discussion about usability!)
    1 point
  29. What I think is wrong with these conversations that keep coming up is that rather than someone proposing a module that does what they want and either building it or getting people around them to build it, they leap in and demand that the ProcessWire developers should drop what they are doing and change ProcessWire to suit their needs. ------ The part in Bold is assuming things which are absolutly NOT true! It is sad Joss, that you interpret things constantly in the wrong way. There have been now several threads about the same problematic and it is always the same people who try to block a development into a more EndUser Friedly direction, or a development of a more module APPS which bring in ready and easy to use solutions. No one hinders you to use Processwire still the way you were using it all the time. Build everything from scratch. But I see a huge community in here at Processwire with very clever people in it like Nico, Apeisa, Kongodo, .... who like to get things done. The easy and clever way! Read the comments to their modules! WOW they are really great and this is also what it should be. A great piece of a software application. Who has said that Joss? I am sure nobody! In a well functionig Open Source community their you will have always people who can code, others who can design, another who can integrate like you, and again others who are great in writing tutorials or as trainers or editors etc. Many different Talents can come together and bring in their ideas and finally probably there will be a or more develper who does the programming, someone who does the design and again others who start writing tutorials etc. All together contribute and share their talents with others! Inspire to share! In all those discussions NO ONE!!! really no one said that the core needs to be touched to achieve that but you always assume it with your posts. Why? When you bring up that discussion to exactly that point you are actually trying to kill it, this is very sad! Why don't you let people discuss those things without those destructive comments! De facto you are right in one point. We need to discuss this in seperate threads as all those threads actually about usability have been turned over by those blocking comments towards a philosophy discussion. The same happened here! - > Reason: Those Threads and even the one I started here gave you actually the chance to put in your "They touch the core" fear discussion. You really need to be much more open for new statements and ideas. Take i.e. TYPO3 as an example of a Content manegenenbt Framework which started pretty much the same way like Processwire. There was ONE single developer who had put all his ideas into that system and than he published it as Open Source Software. "God has given me talents to share the stuff what I produce with all this talents with others who don not have such talents. Inspire to share - or Joh3.16 - Check out the Bible! This Inspire to share idea was so manifested that even the default install tool password was joh316!!! -- I started with that community in 2002 and grew with it. Some grew even faster and some of those actually tried to fly high and tried that TYPO3 stays according to their specific needs which ended in a disaster! as many many people left! To summarize what has been said so far in all those Threads: A. NO PROCESSWIRE CORE WILL BE ENRICHED WITH A BUILD IN WEBSITE BUILDER OR ANY OTHER BALLAST!! Please simply except this finally and don't try to lead the discussions about userfriendliness always again towards this discussion that the processwire core gets blown up and that it is not maintainable and getting to complex etc. This is - sorry I have really to say this - it is bullshit if you rad through all those arguments the people alone since June 2014 brought in about a discussion about a more EnD User Friendly system Please except that the Processwire core won't be touched at all! stop trying to create that fear! But there was always the fear that actually the processwire gets touched to HINDER such a development, for whatever reason. Similar to what happened with TemplaVoila at TYPO3! With every update of the core TemplaVoila got problems because the core devs changed stuff so that everyine who had a TemplaVola site got problems, and even only little ones. I hope that stupid game won't happen if the website builder gets to much attention by the public and Processwire Packages with the Blog, the gallery the SEO, the comments Module and the Website Builder Module with which people can drag and rop their blocks and designs together, when this is getting very popular. I hope that the core will still make these things possible and does not try to stop developments into that direction. Actually Processwire is predestined for a website builder due to the fact that it already is using that great API . If it will be a free Module or a Module like Ryans Pro Modules we will see and is also depending on the support and funds we will receive and will be able to create from i.e. our customers. A demand is already there! ------ B. There is absolutly NO NEED to split things concerning the core development as long as the core stays as is and comforts and does not block both mainstreams. To make it easier it would be nice if the one who is maintaining the Forum could build up a section for WEB-Applications (Websites etc) and another for (All other kind of Apps which are not at all webrelated but can be buidl with processwire) In the WEB-Application section I woudl like to see a subsection about USABILITY here we can discuss about building up some standards, nameing conventions which will make things much easier to share things later on. here we will have a Thread about THEMES - probably there are already some out which we coudl use to start with, beside those of the main installations which actually already use all some standards and conventions. After that section has been setup I will also open up a separate Thread about the website builder module. Yes Joss we will look deeper into it and we will try to motivate others to contribute to that ideas. I am pretty sure that with good teamwork also a good result will be there at the end. This section about the website builder Module will be about the module and its functionality and NOT about if it shoudl be build or not! or why the hell it would be not good to build it etc. If you want to discuss things in that direction than use please another thread. Here are some of the other Thread where the USABILITY got discussed in a pretty much similar direction - with always same results actually. https://processwire.com/talk/topic/7565-making-pw-more-userfriendly/ https://processwire.com/talk/topic/7168-thoughts-after-2-years-of-marriage/#entry68929 NorbertH had originally listed a pretty good list: Most of it is already there but some of it only needs to be put into the right and nicer looking and into a more ergonomical workflow order. I hope Kongodos Gallry Module makes progress as it would be a great enhancment to that prebuild profile with ready to use and preconfigured modules. The Part which needs improvement is actually mostly only the templating stuff because we need to think about some basic standards and naming conventions and thats it. Using Bootstrap 3 with Less (AIOM) Module combined with the SEO Module and a usable Frontend User Management System and the complete Templating Part could already start to make all kind of templates and has as background the same system constellation. If that constellation does not fit the specific needs that there will be a way always to enhance or to reduce functionality. Blog/News - Commenting System with optional Rating Polling (optional) Gallery Module to manage all images, even better if that could integrate with cloudspaces like dropbox, flickr, picasa, etc ... AIOM SEO Basic Forum Contact Form Newsletter Shop (Cart) Frontend User Management Booking Module (Formbuilder ;-)) Caching (ProCache) ... All this is actually already existing and a great base for most of all websites basic needs. Let' start with thatand try to normalize and standardize some Templates so that they are interchangable and in parallel integrate a website builder and of course inline editing in front and backend! Don't discuss thatnow here but keep yor ideas for the new Thread. I hope someone will be able to start new sections! Thanks and have a nice weekend! And Joss - just saw your newly answers - for sure there will be enough support to handle it when more people demand Processwire. TYPO3 has meanwhile a security team and many other teams, a great community, lots of people who contribute and are willing to do jobs like that - security testing, writing tutorials etc - the more people will demand processwire the more people will also be available to maintain core and especially modules. And probably even Ryan is not sad to get some more Jobs! of course all others too.
    1 point
  30. hi zeka, welcome to processwire i switched from seblod to pw some months ago and i hope you will enjoy your move as much as i do! you will be impressed by the great community and the fast and knowledgeable answers you will get here, i'm sure (knowing the pain with seblods forum support...). to your question... coming from joomla/seblod you have to change your mindset a little bit, i hope that i can help you with some comparisons: articles/items (joomla/seblod) = pages (pw) in pw everything is a page! thats very important to understand. pages can store any data you want. it's like in seblod everything is stored in joomla articles, pw stores everything in pages. pages can have completely individual set of data-fields (eg. headline, body, images, starttime, endtime etc.). this setting of fields is defined by "templates": content types (seblod) = templates (pw) in your templates you define which fields will be available in your page. some examples: template "blog-post.php" # field "title" # field "body" # field "author" template "product.php" # field "title" # field "description" # field "price" # field "image" so if you created a new page "product" you would only have the fields "title, desc, price, image" available for editing. list&search (seblod) = selectors (pw) forget list&search types!! selectors are the way to go with pw say we want to display some products with template "product" from above: $products = $pages->find("template=product, price>100, sort=price"); foreach($products as $item) { echo "<a href=\"$item->url\">$item->title</a><br>"; } see here for a quick glance: http://processwire.com/api/selectors/ (yes, everything is very well DOCUMENTED - that's another huge difference to seblod ) don't try to bring editing features to the frontend unless it is REALLY necessary joomla has a very complex backend, so i tried to hide this complexity for my clients by giving them edit access only for some parts of their website from frontend. processwire's backend is so simple that you will not need to hide it from your client anyway: if you have some experience in seblod, i think you will learn pw really fast and enjoy how clear and simple everything can be and now put everything together: https://processwire.com/talk/topic/693-small-project-walkthrough-planets/ if you have no dev-environment you can instantly setup a fresh copy of processwire here for free: https://lightning.pw/ have fun with processwire
    1 point
  31. Are you trying to be funny? Actually is is Comic Avec, not sans.....
    1 point
  32. Er ... depends how brave you are.... Liferay. However, it is a monster and though incredibly versatile and powerful, it takes a huge amount of learning. The advantage, though, is that because it is actually a portal system, the CMS side is just a plugin portlet, as is all the other functionality. So you can build and run a thousand dedicated sites on it. And it also runs as a container, so you can run a php application within it. So, you could add ProcessWire to it, in theory. And it has hooks for everything, so you can get the Liferay and PW database chatting away too. All a bit over the top.... I am sure there are some smaller beasties that make more sense!
    1 point
  33. Sounds like this would benefit from separate "not" / "negate" checkbox, or something like that. Just saying..
    1 point
  34. Just in case you also stumbled upon my Foundation 5 profile. This is outdated, too because I'm not using it anymore. But in the readme.md are instructions how to update.
    1 point
  35. I totally agree with this. I would not be pleased if the core changed but am more than happy to see Processwire further extendable via modules. Nicos WiteThemes idea does appeal to me as far as themes go. This would keep both sides of the camp happy as far as accommodating those that wish to create or sell and use themes for Processwire and I think beneficial to both sides. I am still a little confused why there is opposition to this. I understand that there are some worries that the standard of the forum would go down but this could be sorted by making a dedicated section or forum for such discussions on this topic. It's just an idea before anyone sends the dogs after me. .
    1 point
  36. Just to tell you I'm not a coder, I'm a designer and artist who happens to like coding as it's also a creative process. I used Tpyo3, Wordpress, Joomla, WebEdition, Modx and other CMS when starting with CMS's. I barely could code php. I only struggled with those platforms and had to deal with stuff I didn't want to, be it security issues or updating, learning something arbitrary platform specific. Modx happen to be a tool I worked with before ProcessWire. Within days and many hours I had a prototype of a module which didn't do anything other than say hello. All those system never really let me do what I wanted without getting in the way or installing some plugins that didn't work really. It's because they're too opinionated to be useful in a wider range of contexts. They're all cluttered (I think you got that all wrong). Which all lead to frustration and hours and hours of wasting fighting a system. They try to save you time but in fact they put you in constraints that often make little to no sense. Now all those systems try to solve certain issues by putting yet another layer of complexity and so on. Then I discovered PW and finally I was in charge, saving time, focusing on things that really matter. Within an hour I had my first module "HelperFieldLinks" working without even reading a manual other than the HelloWorld.module. It's so simple, it didn't take me long to see the simplicity and power of PW. I am able to put contrains where the project demands and not the system. It's all so simple even I could as a non coder. PW makes me shine, and people think I'm a good coder. lol. So wrong. I have built websites for my mom and sister, and never had to explain or show them how to edit their site, they found out them self, which speaks a lot of the usability of PW.
    1 point
  37. Teppo has nailed it. It's the unfriendly comments from earlier on that derailed it and hence the replies - it shouldn't be surprising that people got upset when you talk about the death of a platform that is alive and healthy because it's not headed in the direction you want and basically ignoring the many others who are happy with it doing what it does. But let's put that aside for now or we will be going in circles. So firstly, as teppo says, Processwire is a framework. It is possible to extend ProcessWire to work in the way you want, but I know this is frustrating you as you want examples. There are too many examples - I have a whole Intranet running news, asset tracking for thousands of assets, purchase orders and invoicing, health and safety observations, contract information and tracking, ship tracking (with some maps integration) and a knowledgebase that links heavily into the assets so we have instruction manuals and guides on how to fix them as well as their fault history). What I can't do is show you any of it because it was built for a client. So that is a Web application - when its function is to process business data. The back-end of an ecommerce shop to me is an application too. The reason people say "you can do anything" is because you can. Your imagination should be allowed to run wild - because Processwire is essentially a framework that still let's you use PHP you can theoretically build anything you can see out there that is already in PHP but it depends on programming skills to make any of it happen.
    1 point
  38. Please excuse me for referring to myself: discussed "a zillion times" ... This sentence should become part of the forum rules. Maybe some of you know the funny story written by Paul Watzlawick in "The Situation Is Hopeless, But Not Serious: The Pursuit of Unhappiness"? A guy is seeking for his lost keys under a lantern but can't find. Asked if he lost it under the lantern he replies: "No, I lost it somewhere else, but only here is enough light to find it."
    1 point
  39. @Zeka, There would be several ways to do what you want and it will depend on some factors. I would guess that the majority of PW sites that configure products would be using pages to store the products (1 product per page); Your product template would contain these fields: product_name qty_per_unit unit_price You could either use the ProFields lister to make your list as above, or create a page-table on the parent page of the products and then when you view the product parent page you would see that list. - - - - However, if your needs are simpler, then you could use ProFields Table to make a table like you have, and then you would actually be able to edit the fields inline like that. With pages you would have to click to get a modal and then edit the 3 fields. - - - - And then there is yet another way you could do it using a hybrid of both things described above; I'm actually doing this 3rd approach on a site now (and the reason is to save time on entering many rows really fast, but we need the products to be pages for other reasons..) 1.) setup the ProFields table with the fields (and it would look almost identical to your screenshot) 2.) write a simple module to create products (using pages) when you save the page containing the table. The module would cycle through the table and check to see if the product already exists, and if it doesn't it would create the product; it would also check each page-product for changes/edits to the fields and update as necessary; so your Table would become sort of a proxy entry-instrument for the product-pages;
    1 point
  40. @Chris White, I would post any issues about ProFields on the ProFields forum. Also, make sure that you have fully installed the ProFields and see if that error persists. Regarding the upgrade, i'm not sure that you can update ProFields from the admin; Once you make the table field, you do need to configure the column names and types
    1 point
  41. Cool idea. The way I see many people storing objects in databases these days is JSON. There is some slight overhead in decoding big objects inside a database...if you are only grabbing a few fields from each $page object it's probably faster to use process wire's default approach to getting a field data. I'd image if you are getting lots of fields and need most of them to do a calculation then storing whole $pages as JSON inside a noSQL db like redis would give the largest speed boost. You will have fewer queries, you just spend your processor time decoding JSON objects (which should not be that bad). I image a simple module that did this could JSON encode the $page object on $page->save ($page->save is used by all things that save pages including the PW control panel) and store it in the DB of choice, under #page id. if you wanted to pre-populate your current $page object with your cached version you could use. $page->getCached(); or something like that. foreach( $veryComplexPages as $complexPage){ $complexPage->getCached(); //would populate $complexPage->fields with the cached version if available. echo $complexPage->someField; //would use cached version gotten from the command above } As far as I know process wire by default will cache all fields that are set in memory, for example if $page->title is not NULL process wire will not try to search the database for it. This default behavior will make it easy to write a thrid party page cache module that gets the $page fields first. Also process wire also only grabs the fields that you request, so If you don't request a lot of fields you will have minimum interaction with the database. --- Caching the $page->find() style functions. The methods above do not seed up queries to the database that are string search related such as $pages->find(), which is probably the kind of queries that are taking up a the much of the overhead. if you wanted to store the results for those you would need another cache, maybe that stored page ID's returned from the $pages>find() method. EXAMPLE: $pages->find('body=*"somthing to search for"')->cache('2 days'); One could use the API hook of the find() method, and use a hash of "body=*"somthing to search for" as a key to store the resulting page ID's in redis or MYSQL. That way you could save the results of huge and complex queries for a latter time as a list of page ID's. This type of cache would also be harder to invalidate but it could still be done on save(). To do so you would have to search the results of all find queries that where ever cached looking for the a page ID that has changed. (that is going to be faster in MYSQL then redis), since you can't query redis. --- would love to hear if any of these solution might be terrible and not work as I will be needing to implement some variations of them in the future.
    1 point
  42. I don't know how you did it... but it all seems to work now! Thank you.
    1 point
  43. Or you can use wireRenderFile a new addition to ProcessWires functions: https://processwire.com/blog/posts/processwire-2.5.2/#new-wirerenderfile-and-wireincludefile-functions echo wireRenderFile('markup/contact-markup.php', array( 'name'=>'john doe', 'address'=>'sample street', 'zip'=>'sample city' )); I did not test this example, but according to the docs it should work like this. Requires ProcessWire 2.5.2
    1 point
  44. Who is signing SHA2 certificates? We mostly use namecheap.com and even the ones bought a month ago are SHA1 according to the tool posted :/
    1 point
×
×
  • Create New...