WordPress.org

Ready to get started?Download WordPress

Forums

Modernize the Codebase - A Plea from a WordPress Plugin Author (8 posts)

  1. MarcherTech
    Member
    Posted 11 months ago #

    I have been in utter hell for some months.
    I come from a world where OOP is embraced for what it is, a godsend unto maintainability.
    Where backwards-compatibility is respected in minor point versions. Where multiple 'plugins' or 'hacks' can, and often do simply play nicely with one another without conflict or code modification therein.
    Where 'themes' are simply meant to display the data, not add additional functionality, and mancode, or business logic as some call it, is never to be found therein.
    Where pollution of PHP Userland with global variables and functions is rightly considered a sin.

    I implore the maintainers of this Open-Source code, think about those who work to integrate against your code, and ask yourselves, why, when PHP4 is not just EOL, but DEAD, WordPress is still a procedural mess with objects here and there?
    Why is it you have a plethora of plugins, but so very few that have any staying power to stay supported throughout the latest and greatest version?
    Why you continue to stack features atop this codebase without rewriting it is beyond me, as it cannot be sanely maintainable in any fashion at this point, I am merely a plugin author and I am starting to lose it simply trying to maintain that plugin in this procedural wasteland.
    Your Codex examples all use global functions, why? The most basic beginner of PHP should know what a class is, it is as basic as expressions to the language, and is no complex subject.
    Ask yourself seriously why so many modifications are implemented as 'themes' instead of 'plugins', thereby limiting the ability to be used with any theme.
    Most of all, ask yourself how many times you have had to scan a 2k-line file of completely unrelated global functions to fix a bug(pluggable.php, I humbly submit, is a joke, it is 'pluggable' for the FIRST to overload it, and *no other*). How much of your HTML is in your PHP, and vice versai. How many times the 'global' keyword has to be used. How the future of this codebase will fare, when the next dev down the line has to hunt through these global functions to fix anything, much less add a feature.

    Can you please stop stacking features in atop this aging and fairly flawed codebase, and for a major version, rewrite it using current standards? Please?

    As it stands, I am having to wrap this procedural mess in my own abstraction layer just to use it in a centrally maintainable manner.
    I have many 'plugin' and 'theme' conflicts I can do nothing about by design of the wordpress codebase.
    *Every* minor point version of wordpress breaks *something*. I do *have* to support the code I write.

  2. Andrew
    Forum Moderator
    Posted 11 months ago #

    It doesn't look like WordPress is going to change its manner, can you try another CMS? Something MVC-based perhaps?

  3. I do *have* to support the code I write.

    Well ... yeah.

    WordPress is 10 years old. That means, without scrapping and restarting, it's not simple to fix all those things. So you have to take it as a constant work in progress. As time goes by, things ARE fixed. If you want to help, please join us in core development. We have a LOT of tickets in http://core.trac.wordpress.org/ that would love the attention of someone with your skills to address EXACTLY the problems you're raising :)

    Keep in mind, we will want to keep backwards compatibility.

  4. MarcherTech
    Member
    Posted 11 months ago #

    My fate in that regard is sealed. I cannot.
    However, that response simply helps my argument. How many developers will simply throw up their hands and walk away? Why do you encourage this? How can the maintainers not see the horrifics they put any plugin author(and themselves) through? WP succeeds here by free access and pretty UI alone.

  5. MarcherTech
    Member
    Posted 11 months ago #

    WordPress is 10 years old. That means, without scrapping and restarting, it's not simple to fix all those things.

    And this is exactly what I ask you to consider. Start it fresh, I truly do not care that I would have to rewrite my plugin, I would welcome it.

  6. MarcherTech
    Member
    Posted 11 months ago #

    Keep in mind, we will want to keep backwards compatibility.

    This would moot the point. I agree in minor point versions, yes. But a major rewrite is needed, or this legacy codebase will eventually drown in it's own maintenance. This will indeed have to break compatibility with previous major revisions.
    Upgrading the database, surely, but the code? You have a jumbled mess of global functions NOW that exist for no more than proxy, and are more often than not buggy.
    I would far rather have a fatal error tell me xyz function does not exist than for the function replaced to silently fail.

    When one's code is a jumbled mess, a proper developer re-factors. They do not just ignore the mess and add more features.

    I, personally, have far too much of my own code to maintain, and do this for a living, thus I cannot spend time contributing to WP core.
    That said, the amount of work maintaining and supporting one WP plugin is equivalent to the entire rest of my many creations.
    I created this topic merely to see if the current maintainers have any interest in modernizing the codebase, if I had the time to devote, this topic would not exist, instead you would have a commit the size of which has not been seen in years.

  7. Since I don't see your plugin here - http://profiles.wordpress.org/MarcherTech - I can't guess what you've done, but in general, most plugins don't take that much time to maintain.

    BuddyPress, bbPress, Jetpack, Disqus, and the like of the BIG plugins are totally different, of course.

    We would LOVE you to contribute to core. Yes, it takes time, but it'll be faster than waiting on other people. Even just an hour a week helping out gets us there faster.

    (BTW - The backwards compatible is mostly for old plugins that are doing_it_wrong, as we like to say)

  8. MarcherTech
    Member
    Posted 11 months ago #

    (BTW - The backwards compatible is mostly for old plugins that are doing_it_wrong, as we like to say)

    The core developers are Holding It Wrong™ then. Do tell, what is a third-party dev going to do when there is a well-documented set of global function procedural, and no visible code breakage as you power on using the same global functions? They keep using them. You keep using them.

    Since I don't see your plugin here - http://profiles.wordpress.org/MarcherTech - I can't guess what you've done, but in general, most plugins don't take that much time to maintain.

    BuddyPress, bbPress, Jetpack, Disqus, and the like of the BIG plugins are totally different, of course.

    Proprietary SSO+Bridge. It is not in the public domain, but I feel willing to share some minor woes....
    The closer you are to the core, the more inconsistencies you have to put up with. This is a method in one of my objects:

    /*
    	 * checkAuth. wp_authenticate hook.
    	 * <=3.6.0 sends two strings, 3.6.1 sends an array with a size of 2
    	 */
    
    	public function checkAuth($username, $password = '') {
    		$nameOrEmail = is_array($username) ? $username[0] : $username;
    		$password = empty($password) ? (is_array($username) ? $username[1] : $_REQUEST['pwd']) : $password;

    A hook point was changed in 3.6.1, quietly, caused quite a fuss when nobody could login. Ok, whatever, so be it, it happens. The next however is truly a sore.

    if ($ipsConnect->isEnabled()) {
        function wp_logout() {
    	$id = get_current_user_id();
    	wp_clear_auth_cookie();
    	do_action('wp_logout', $id);
        }
    }

    Do you see the insane logic here? However could one even do anything non-trivial on wp_logout without conflict guaranteed when we don't even know *who* logged out? I end up overloading the global function just to pass it to the action 'hook' so I can actually use it. This is just a casualty of this procedural methodology. I do it this way because it raises the LEAST conflict, but I should simply be able to extend a called object, and do what I need to do and let others do as they need to in the first place.

    We would LOVE you to contribute to core. Yes, it takes time, but it'll be faster than waiting on other people. Even just an hour a week helping out gets us there faster.

    You simply do not understand how truly bad it is.
    You could simply rewrite the entire thing to use Laravel and Twig or Smarty and be 99% of the way there, and as free open-source, you legitly could. However, this is not something you can incrementally do, we are talking about modernizing the very core of wordpress to be tolerable and sane to the modern PHP code standards.
    However, it seems everyone is waiting for everyone else to do a major rewrite. Have fun with that, and enjoy PHP 5.5.

Reply

You must log in to post.

About this Topic

Tags

No tags yet.