• 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.

Viewing 10 replies - 1 through 10 (of 10 total)
  • Andrew Nevins

    (@anevins)

    WCLDN 2018 Contributor | Volunteer support

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

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    πŸ³οΈβ€πŸŒˆ Advisor and Activist

    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.

    Thread Starter MarcherTech

    (@marchertech)

    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.

    Thread Starter MarcherTech

    (@marchertech)

    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.

    Thread Starter MarcherTech

    (@marchertech)

    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.

    Moderator Ipstenu (Mika Epstein)

    (@ipstenu)

    πŸ³οΈβ€πŸŒˆ Advisor and Activist

    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)

    Thread Starter MarcherTech

    (@marchertech)

    (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.

    I made one theme and one plugin with WordPress, and the experience was so awful that I will never try it again. The codebase doesn’t seem to have gone anywhere since it was first written.

    To anyone else coming across this thread, OctoberCMS is a nice new CMS that I found, and it’s written with Laravel, so the code is actually beautiful.

    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.

    Mika, are there plans to do a rewrite of the core to bring it to OOP?
    If yes, I would have at least two hours a week to contribute πŸ™‚
    But going back to a procedural code base is just a no-go for most devs.

    You could simply rewrite the entire thing to use Laravel and Twig or Smarty…

    Well, mentioning Twig is fine, but Smarty… I rather use php code in templates than. Laravel is nice, but also slow… even the Joomla Framework is faster xD

    To anyone else coming across this thread, OctoberCMS is a nice new CMS that I found

    Also Pagekit is very nice, but both have in common their misuse of “return” even it’s only for config files, a file simply should not return anything…

    Thread Starter MarcherTech

    (@marchertech)

    Mika, are there plans to do a rewrite of the core to bring it to OOP?

    All I was ever looking for was some indication of plans to do this.
    My best advice? Flee. 4.0 proves there is no interest in fixing this crumbling house. Major versions are the only real time one can get away with the massive code-level changes needed here. The opportunity was ignored. Support of the modification in question was literally killing me slowly due to lack of sleep and being overworked figuring out issues not even my doing because the code core is so conflict-prone due to it’s procedural nature. I have given it away, I am not going to wait around for 5.0 in the hope of seeing an OOP rewrite, only to see the same disappointment I face with 4.0.

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Modernize the Codebase – A Plea from a WordPress Plugin Author’ is closed to new replies.