• Resolved jimf81

    (@jimf81)


    Hi

    Something that I think WordPress could benefit from and frankly I think it would be a good time saver is the ability to add standard swatches in the settings, which subsequently appear in the wysiwyg.

    Why you may ask, well it is a pain in the rear when creating a site with 5 or 6 colours that you have to add each time in the wysiwyg.

    Maybe an option for 10 colours you will use in the settings of wp, add the hex color for each and these colours appear in the wysiwyg for every post, page, cpt or whatever.

    Currently the color can be added to the swatch of the specific WYSIWYG but not for across the site.

    I’m sure this would benefit most WP users and correct me if I am wrong but this should not be too heavy to implement I guess? Adding a plugin to do this might be ok but seems more logical to have it built into WordPress.

    Many of us are surely using client or business specific colors so this makes sense. Copying hex colours every time you need them to the wysiwyg is just annoying.

    Thanks

    James

Viewing 5 replies - 16 through 20 (of 20 total)
  • catacaustic

    (@catacaustic)

    I’ll use an example from the URL’s that you gave before.

    http://www.u2.com/index/home

    There’s absolutely no reason to hard-code that page in HTML. That page should be a template that draws the content from many different areas around the site. Take it in sections down the page:

    • Sliding images at the top – taken from news.
    • The Latest – Again, from news but using more low-level categories
    • Connect – Basic info in the template, but drags content from each social network
    • Watch – Show the latest item in videos
    • Listen – Same but with audio
    • Poll – show whatever current poll is running
    • Photos – Show the latest photos

    What this shows is that the content in each section comes from somewhere else around the site, and all of the areas link through to those sites. Why would you want to hand-code a page like this when it’s all dynamic? Think about it… add a new photo, update the home page manually. Add a new news item, update the home page manually. Add a new video, update the home page manually. And that’s just the home page, what happens if any of these items are shared or linked on other pages in the site? Form some sites that I look after there could be 20 different pages referencing “Latest XXXXX” and doing things your way would mean going through each of those pages and updating things manually.

    That is why we use templates and why we don’t want to hand-code a page like that. There’s way to much change of breaking things.

    Thread Starter jimf81

    (@jimf81)

    So I have 2 folks saying that WordPress is not FrontPage or indesign. My goodness gracious me I have never said that it should be! Don’t try to win arguments by using anything you can please!

    “It’s designed to help people without that sort of knowledge to build websites and publish their content online.” Said Sam.

    Yes it is, that is why it is a huge pain in the rear end having to store 10 hex colors in a word doc and to keep going back to them every time you need them in the post editor! Why on earth would any client like that, that is why we need this solution because it is client centric. Put your customer first, who want to edit their pages. Highlight, click, done!

    @catacaustic of course I do that sort of stuff but there are times when pages need their own approach. I combine those principles with giving clients the freedom to make changes.

    You can try whatever angle you like to prove how those examples pages I provided could be created but there is no excuse for not having a highlight, click, save solution for colors.

    I’m not saying they will but don’t let people think for one moment about moving to wix or some nasty solution like that. Viewpoints of this nature are not client centric but more focused on how much the developer can control the client.

    4 points:

    1. Client should understand a whole bunch of code has been completed for their site, so they can’t do everything, this includes templates etc.
    2. Colors are in the theme and used where required but flexibility should be in place elsewhere.
    3. Client should not have to go anywhere near hex codes or html when changimng colors in the post editor. Templates help but they should have some freedom!
    4. Client should have flexibility but giving them the option to mess with hex codes and html, obviously this can be problematic. Highlight, click, save because the color is there in the editor. That is a customer centered solution.

    There are plenty of ways a developer controls a client on purpose or inadvertently. This is not one of them!

    If you can click a font, click to justify, click to add a bullet point, why is clicking for a specific a color you need each time such an issue?

    So if WordPress is designed for people who don’t have extensive development skills, surely a color feature I have suggested is exactly the addition required.

    When WordPress took away the color picking option a few versions back, leaving post editors users with only being able to add exact colors in the html that was bonkers, many were unhappy about that. Once more, clients furious and for good reason in my eyes. If the client can’t use it fast and efficiently it is not fit for purpose.

    Jon (Kenshino)

    (@kenshino)

    Lord Jon

    Feel free to drop a ticket in trac if you feel this is a big deal. Simply mark it as enhancement.

    This discussion died the moment the post editor was described as being used as a development tool.

    Thread Starter jimf81

    (@jimf81)

    Precisely but I have to argue against others who have drifted where it shouldn’t have gone. If the post editor is not there for any development small or more, why is it there at all and why does it currently have options to choose font, bold, alignment and so on. Remove them all if this is the logic that is being presented.

    Moderator James Huff

    (@macmanx)

    Volunteer Moderator

    Precisely but I have to argue against others who have drifted where it shouldn’t have gone.

    No need to continue the argument, there’s really nothing more that can be accomplished in this thread on a support forum, so I’m closing it down.

    As Jon mentioned, “Feel free to drop a ticket in trac if you feel this is a big deal. Simply mark it as enhancement.”

    There, you can continue the discussion with the developers behind WordPress.

    Though this guide is about reporting bugs, it sums up the general process fairly well. Just make sure to mark yours as an Enhancement, not a Bug: https://make.wordpress.org/core/handbook/reporting-bugs/

    If you absolutely feel this must be in core, you must file it in Trac. If you continue here, it’s nothing more than an argument that will go nowhere and is of no value to the support community.

Viewing 5 replies - 16 through 20 (of 20 total)
  • The topic ‘Standard Color Swatches’ is closed to new replies.