Jump to content

larrybotha

Members
  • Posts

    38
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by larrybotha

  1. Thanks, apeisa, this is awesome.
  2. I'd love for ProcessWire to have this feature. Are there any plans for work on this module to continue?
  3. @joe - that video is coming straight from YouTube - nothing fancy on our side. The nav glitches are definitely not intentional! Which browsers / devices did you get those results on? I see you're on Opera - I'm guessing Opera Mini, since Opera Mobile tests were all perfect. Opera Mini is a mysterious beast. We'd better take a look (seems like a weird stacking issue with the logo, which is bizarre considering the nav is in a completely different context). EDIT: the main wrapper is not shifting off-page - most likely some sort of issue with Opera Mini and CSS translate. Stacking is still bizarre, though. @diogo - ye, the dropdowns have bothered me a while. I'm iffy about not having a pointer on the link, but I agree, I think we need to remove the hover state at least. Haha, you don't want to know what went into making the illustrations on our site, and then getting them to work responsively! The response has been great, though, so well worth it. It does need a port to ProcessWire - but I'm terrified of touching those headers again O.o Thanks for the kind words, guys
  4. Hey guys, This is Fixate's second PW site - first one launched. It's for an orthodontics practice based in Johannesburg, South Africa. http://hugoorthodontics.com This site was built with an earlier version of our PW MVC Boilerplate on Github, with a discussion in the PW forums. Since abandoning WordPress for ProcessWire, we've never been happier with the flexibility in design and development! Thanks for an awesome product
  5. awesome, thanks for the quick response, SiNNuT! I was running out of things to search in the forums - I was almost there O.o
  6. Hey guys, Struggling with some formatting in TinyMCE. What I'm looking for is WordPress' wysiwyg behaviour where a user can add as many linebreaks between paragraphs as they wish, and a nbsp is used for each line-break. i.e. lorem ipsum dolor sit amet <enter> <enter> <enter> morus lorem ipsumus yields <p>lorem ipsum dolor site amet</p> <p> </p> <p> </p> <p>morus lorem ipsumus</p> Currently, TinyMCE strips all white space. nbsp can be added manually, but I don't want our clients to have to worry about how or when to use it, or which areas of content to be careful about editing. I've looked at a number of options to set for TinyMCE, but their documentation is pretty cryptic, and none of the options I've tried have given me the result I'm looking for. Any help is appreciated!
  7. Good point SiNNuT. We'll have to test the minimum PHP version, as we're using traits in there. We're using PHP 5.4, so 5.3 will have to be tested against. There's still a fair amount of work to do in terms of the docs, but we'll get there eventually. I'm actually a total PHP noob - most of the magic in there is not mine! Reading through how things are being called, required, and included should shed some light on what's going on - we've deliberately tried to keep files as light as possible.
  8. ok guys, there have been some major updates to the boilerplate. Check it out at https://github.com/fixate/pw-mvc-boilerplate, and take a look at my original post for a few details on the updates. Things are far neater
  9. For those who may have struggled to get TinyMCE to save colours, make sure to add `span` to valid_elements, in addition to the style attribute. valid_elements should look like the following to enable users to set their own colours (in addition to adding `forecolorpicker` or 'forecolor' to theme_advanced_button[n]): @[id|class|style],a[href|target|name],strong/b,em/i,span,br,img[src|id|class|width|height|alt],ul,ol,li,p[class],h2,h3,h4,blockquote,-p,-table[border=0|cellspacing|cellpadding|width|frame|rules|height|align|summary|bgcolor|background|bordercolor],-tr[rowspan|width|height|align|valign|bgcolor|background|bordercolor],tbody,thead,tfoot,#td[colspan|rowspan|width|height|align|valign|bgcolor|background|bordercolor|scope],#th[colspan|rowspan|width|height|align|valign|scope],code,pre
  10. No problem, landitus! Matthew, I'd love to know others thoughts on an MVCish approach. I'm new to the concept, and am learning about MVC primarily through Rails, so I've got a lot to learn. A friend in our office is more of the MVC guru, so a little of this has been guided though his expertise. I had great success moving some features of the search template into the controller last night - I'm really happy with the outcome (although there's room for a little polish). I'm excited to get working on abstracting the sitemap to its controller, and then eventually adding a basic contact page in the same way, but I'm confident that this approach will assist in keeping my templates organised and maintainable. One thing that I can see being useful is if there are shared helpers - files which contain shared logic, say for forms, that are specific to multiple templates, but not appropriate for the global controller. I'm not sure how these can be implemented in a nice generic manner, but I'll be giving it some thought.
  11. Hey guys, I'm new here, and I'm loving ProcessWire and the community spirit so far. We're just about to start using ProcessWire for our new clients requiring PHP solutions. Moving in a Rails direction, structure in our projects is becoming more and more of a necessity. As such, I've tried to employ some MVCish techniques in creating a boilerplate for ProcessWire for getting projects going quickly. One of the primary goals of this structure is to make it easier to separate logic from markup, and to prevent tags from being split over templates. Keeping `body`, `html`, and structural markup open and close tags in the same file greatly reduces cognitive overhead, and reduces opportunities for mismatching tags to exist. This approach also reduces duplication, and is great for keeping files small, focused, and organised. The main structure of the boilerplate is well defined, and ready to use in production. The repo is available here: https://github.com/fixate/pw-mvc-boilerplate (link updated 2014/01/17) Structure Although not completely MVC (using classes for controllers feels redundant, there are no models, and a full MVC approach will require a fair amount of customisation), it is heavily MVC inspired. Additionally, the structure is an extension of Soma's delegate approach. File structure: ├── site ├── assets ├── modules . . . ├── templates // boilerplate contents here ├── assets // css, js, fonts, images, etc. ├── controllers // variables and functions specific to templates ├── errors ├── partials // markup not specific to any particular template ├── views // layouts specific to a template ├── _init.php // used to load global and template-specific controllers ├── main.php // the 'alternate template' for all templates . . . **NB: This structure has largely been updated and improved - see the UPDATE - 2014/01/17 at the bottom of this post! Controllers Controllers hold template specific variables and functions. There is also a global controller responsible for making global fields, such as SEO fields, available everywhere, as well as being responsible for the actual delegation. Template logic should be handled as much as possible from within controllers. Views Views are responsible for handling markup and output. Views have available to them both the global controller, and their own controller. Logic should be, as much as makes sense, handled in a controller, with the view pulling the results in for display. Partials Partials hold markup not specific to any particular template on its own, such as the `<head>`, header, navigation, scripts, or footer. As with views, it is best to keep these as logicless as possible. _init.php _init.php is responsible for making controllers available to views. Controllers are only included if they exist - sometimes a template-specific controller may not be necessary, in which case you won't need to create one. main.php main.php is the default layout (equivalent to layout/application.html.erb in Rails) into which everything is rendered. This file has been kept small deliberately to let partials and views manage more fine grained markup structures, while this file serves the main site structure. A call to render_view(), defined in global-controller.php, is responsible for delegating rendering to the view of the current template. Additionally, there is a constant defined in globals-controller.php useful for serving different assets depending on if you are working in a local environment, or if your site is live. This is useful for preventing Google Analytics from running in a dev environment, or for using unminified scripts for debugging. This boilerplate eliminates the need to do much configuration when beginning a project, apart from having to change each template's alternate template in the admin. I hope this will assist in quickly organising and developing new projects! ------------------------------ UPDATE - 2014/01/17: ------------------------------ All files for rendering are postfixed with .html.php in good ol' Rails fashion. main.php has been removed in favour of mvc.php. mvc.php requires config/boot.php which then handles which controllers, views, etc. are used the main layout is now found in views/layouts/application.html.php - like Rails again. partials are now kept inside views/ each page template can have its own optional controller, or simply inherit functionality only from ApplicationController ├── site ├── assets ├── modules . . . ├── templates // boilerplate contents here ├── assets // css, js, fonts, images, etc. ├── controllers // variables and functions specific to templates ├── core // core mvc files - base controllers etc. (project specific stuff does not go here) ├── errors ├── views // folder for template files, layout files, and partials ├── layouts // application layout ├── partials // markup not specific to any particular template ├── mvc.php // the 'alternate template' for all templates . . .
  12. I'm building up a ProcessWire boilerplate for quick starting the post-installation work. I've got a basic .gitignore which covers ProcessWire ignores, as well as other ignores for the rest of the project. You can find it here: https://github.com/fixate/pw-boilerplate/blob/master/!root/.gitignore It's based off of Ryan's SkyScrapers .gitignore: https://github.com/ryancramerdesign/ProcessWire/blob/master/.gitignore but keeps certain files, such as .htaccess (we use a custom one which extends ProcessWire's with H5BP's), in the repo so that they are available to team members. For this same reason, we never ignore .gitignore itself; it must be available to all team members. You can safely remove the styleguide and Grunt stuff if they're not part of your projects.
×
×
  • Create New...