szabesz

I'm interested Thanks is advance.

Hello @handzain Welcome to the Forums and ProcessWire! You have finally arrived at the right place

Humanity should stop the "Internet of things" madness before it is too late:

Yep, true, of course, it is not always just about adding a field here and there... So while my "migrating workflow" is simple, it comes with the issues you mention, so yes, sometimes I do have to try things out on my machine before I redo it on the live site, but this does not happen every day. And also true that "maintenance mode" with kindly locked out users might also be needed sometimes. To get around the problem of missing files, I use Beyond Compare, the fastest an easy to use diff tool out there. When it is set to e.g. ftp 8 simultaneous connections, it can deal with a site in 10-30 seconds or a few minutes, depending on the number of files. I only use git to manage my own code. EDIT: My bash script can also migrate/clone complete sites in a minute or two, just in case a need another "branch" of the whole site to work on something that takes long and should not interfere with my regular mirrored version of the live site.

@thlinna I do not know if it will be of any help, but I myself do not migrate any db at all. Instead I build my workflow around this: http://tltech.com/info/mysql-via-ssh/ I put together a bash script to completely automate the process, and normally I can clone the live db to my local machine in seconds (small databases...). This way I always have to work on the live site to make all the necessary changes, afterwards I have to clone the db, but it is an easy to follow workflow and dead simple It might be too simple for teams, but a solo developer cannot go wrong with it, at least I'm quite happy with it, I got used to working this way. Sure, I have never had to work with really big databases, but these days even transferring dozens of megabytes does not take long.

I couldn't have said better myself This was the most important message I was trying to get through but I had been lost is some details, I suppose. Generally, the more options we have the better, but there is one thing that generates unnecessary extra work and that is being "non-multilanguage". By implementing something like this in the core, the question of "should it be multi-language or not" could be eliminated: While we are at it, @adrian's Admin's Restrict Branch module is based on similar principles, so maybe both could find its way into the core. Anyway, since the ProcessWire community mainly comprises developers who are already fine with the own way of building frontend from "scratch" (probably they use their own base profile or equivalent boilerplate), it is hard to see that without you leading the way such a community effort could be successful. Judging by the low number of responses to my proposal, current developers are not too interested...

Thanks for the reply Ryan! Well, it certainly points in that direction, however I was trying to explain something different which should fit ProcessWire better (in my opinion, of course...). Although this sort of “standardized community profile” could be ready to be used out of the box, most of it would be customizable by developers and “brave enough site owners” only (who dare tinker with code), meaning it should mainly provide code level interfaces (for blocks), hooks (to add and remove blocks), etc... I called them widgets, but let’s call them blocks (or whatever) if it is misleading. By providing a solid starting point for non-developers, more beginners or simple bloggers could choose ProcessWire which would boost the user base, but that in turn should attract more developers too.

@Neo Have you seen this? You might utilize it on the frontend with something like: http://www.hongkiat.com/blog/useful-calendar-date-picker-scripts-for-web-developers/ Do not forget that you might want to let your users partially access the admin, so that they can do both... But this is just an idea.

Hello ProcessWire community, Here is my proposal: “ready-to-go profiles” Why more than one? Why not put all the effort into a sort of “standard” way of implementing the frontend. Something that is a versatile and officially supported way of building a site profile. Of course, it should not be forced upon anyone, so that the “blank profile” is always there for those interested. I’m not proposing to change the current philosophy, rather I suggest that we add an additional layer on top of it. There could be only two site profiles that comes with the system: blank and “community”. This so called “community” profile should be: Updatable by site owners in an automated fashion just like modules with the ProcessWireUpgrade module. Hookable, so that part(ial)s of it can be removed and added, meaning it can be changed to one’s needs in a way that is supported by the core. Well documented so that others can easily use it, contribute to it, and can implement custom “widgets” and/or partials that can be used by anyone. These so called ‘Widgets” (template partials / blocks / whatever we call them) would need to implement a standard interface so that the Widgets can be wired into the system no matter what sort of Templates and Fields are used by the backend. With a little bit of code (writing the proper selectors, etc..) the widgets could be wired up to the system, in an officially supported and documented way. This profile would come with standard blogging and portfolio-site like tools already implemented, ready to be used and extended. Any of the implemented features should be easily disabled, as opposed to all the “junk” that comes with WordPress for example (where implementing hooks are required to remove things like RSS, oEmbed, emoji, etc...) If there are features like these, site owners should be able to turn them on/off, nothing should be forced upon them. This site profile should also support something similar to the Css Zen Garden philosophy, so that not only widgets/blocks can be added/removed, but the profile can be “skinned”. These skins could be interchangeable. It would be multilanguage with features suggested by Adrian. To summarize: by working on only one but a versatile and updatable site profile, the whole ProcessWire community could add their bits to it, finally there could be a standard to which one can optionally adhere to. The backend could utilize the very same/similar methodology, so that the community site profile and the admin share the same grounds. It was already mentioned that the backend might introduce UIkit, so this site profile should be built upon it too. For example, imagine being able to utilize the ProcessWire form API on the frontend, fully supported by the site profile’s css framework! Those who use this “community” profile (or any other UIkit based profile they implement) could optionally share UIkit with the system too. I am one of those who would mainly stick to such a profile but it is easy to see how this would help beginners and professionals, and the ProcessWire project too. Cheers

You are welcome. Now some more specific pointers you might want to check out: newsletter subscription: https://github.com/justb3a/processwire-newslettersubscription dealing with surbscribers: relationships between data: http://blog.mauriziobonani.com/processwire-basic-website-workflow-part-1/ Forntend users: Do not be afraid of using modules, but always look for ProcessWire 3.x compatibility...

Or you might want to do it by using Google. Ryan's blog post might help you get started: https://processwire.com/blog/posts/composer-google-calendars-and-processwire/#the-google-client-api-module To tell the truth, I've never used Google Calendars myself, so I do not know how well it could fit your needs, but some of my friends rely on these Calendars and use them to manage reservations.

Okay, finally I figured out that I was fiddling with the wrong settings, so that is why it "did not work". Thanks to @Juergen who was kind enough to take a look at it! Edit: Black Friday, eh?

I see, thank you once more. Well, I dunno, it is not working "here"

Thanks! What is the firts one with 100%? I simply have two 50%, or 30%-30% or whatever, but the result is two 100% wide "columns". Strange... But thanx anyway. I will try to figure it out somehow.

Thanks @Juergen! But how did you do the columns? No matter what Column Width settings I use, I have 100% width fields in my repeater... Am I missing something?

WOW, that is a very compelling way of reporting a bug

Hello and welcome, Well, ProcessWire is perfectly suitable for such a site you described (actually for any website you might happen to build...), but it is not the sort of CMS you can just click together like a WordPress site. Sure, creating your database entities (Pages and Fields) is a piece of cake even for beginners, but you will need to spend time on actually writing code to Wire things together. Learning ProcessWire based development is a sort of linear learning "curve" (linear curve? huh... ) but takes time and patience nonetheless. However, it is also a lot of fun, especially when discussing things here in the Forums

I recommend: http://materializecss.com/ I'm the type who likes css "frameworks”. It is because I do not spend hours working with css, neither do I have the time to fight browser incompatibilities. Those with a decent knowledge of css and supporting technologies (like preprocessors, task runners, etc..) generally do not like Bootstrap like frameworks, especially if they do not work in teams. They tend to like low level “frameworks” (or just simple css grid packages) that give them more freedom, or they do not use any of these at all, or perhaps just their own. However, I think it can be quite useful to learn one of these, because if you are not developing frontends on a daily bases, then they can speed up a lot. Sure, there are situations when one finds the chosen framework to be an obstacle when dealing with a particular problem, but still, they can be really useful. I spent a considerable amount of time to find an easy to use versus versatile and feature rich framework and I think Materialize CSS is the way to go for "experienced beginners" like me. If you are also in this “category”, then I highly recommend it. One can even easily customize it by vanilla css overwrites if you do not want to go the preprocessor way (just yet). Out of the box solutions like Bootstrap, UIKit and others are most useful for teams working on the same project, as these packages define the standard to which everyone can adhere to, so that is why UIKit for the ProcessWire admin would be a good choice, for example. However, solo freelancers working alone have more freedom regarding the path they choose to take...

Can't wait!

It depends on what you are referring to. If you are referring to what is actually stored in the db, then you are right, but if you are talking about what is being sent to the server, than your statement it is not quite true, since hacking is all about changing the latter. On the other hand, I agree that in the case of checkboxes it is more about validation than sanitization, just like explained in the comments of the accepted answer here: http://stackoverflow.com/questions/26327953/sanitize-a-value-from-select-radio-checkbox

Now that you mentioned @Soma's Page Edit Soft Lock module, the question is: why hasn't this been added to the core since 2012? It is just a few lines of code wich can even be shotened (the module config part of it), but it sounds like a must have feature....

It is true. But watch out for this: https://woocommerce.wordpress.com/2016/10/27/the-new-crud-classes-in-woocommerce-2-7/ "How will this affect existing plugins? If you do anything with product, customer, orders, and coupons, you will be affected in some way. Even if you do a simple update meta call. This won’t break immediately, but your code will not be future proof. As soon as the schema changes in another update, your code will fail." So choose only those plugins that are likely to be updated in the future. Also, keeping an eye on WordPress I can see that lots of breaking changes are ahead. Sure, they will probably not be introduced without some sort of deprecated code support, but not updated plugins will cause a lot of troubles for WordPress users in the following years to come...

This is a four part tutorial that should get you started: http://blog.mauriziobonani.com/processwire-basic-website-workflow-part-1/

Thanx a lot! I wish it was part of the core...